Agile Testing with Lisa Crispin

This afternooon, I joined Mike Sutton’s Improv session. My takeaway: “It doesn’t hurt to collaborate”. The exercises were fun and funny, and gave insight into how teams worked together. I particularly liked that Mike used a task board to keep track of his session.

Mike Sutton moving cards on talk task board

We did a lot of fun exercises, and had lots of opportunities to do the “failure bow” (similar to “How Fascinating” in Language Hunters) we learned from Tobias in the warm-up this morning. We encountered so many things that happen on software projects. For example, when we had to draw a picture by committee, each person had a different viewpoint on the picture and a different idea of what we were drawing.

Ball Flow Game

Next, I joined the Ball Flow Game facilitated by Olaf Lewitz and Gerry Kirk. This turned into a hilarious example of “too many cooks in the kitchen”, in my opinion. Just try to get a bunch of agile coaches together and get something done! We started out really well, producing the inventory of “magic balls” efficiently, in just over one minute.

Then, naturally, since we had done pretty well, we changed everything at once and came up with a totally new way to “deliver” the magic balls. My personal estimate of five minutes was not too far off the real result. It was a good opportunity to reinforce the fact that it is better to do small experiments and only change one thing at a time than to do a drastic reorganization.

Attempted Game Development

Paul Boos, one of the ACCUS organizers, was kind enough to let me take a slot in the agenda to get help in trying to develop a game that would teach tester-developer collaboration. My goal was a quick game that would teach testers that it’s not a bad thing to test early and often, and teach programmers that it’s valuable to have testers involved throughout development. I can’t afford Legos and I don’t like to check my bag when I travel, so I wanted to do something with a construction kit that uses plastic straws (similar to drinking straws) and connectors.

Some participants created works of art!

A wonderful group of people came to help. They started throwing out ideas, and it first, it seemed there was no way I could create the kind of game I wanted with the straw kit. While they brainstormed, participants built some awesome straw constructions, proving that using our hands does help us learn and think!

It turned out that you can build a lot of two-dimensional shapes with the straws: squares, rectangles, circles, arches, hexagons, lips. The group proposed that the first part of the game would be for each team to build all the shapes. These could be “tested”. In the second phase, each team would put the 2D shapes together into 3D shapes, and try to build the biggest structure that could hold its own weight when picked up. This also would encourage incremental testing.

An additional idea was to throw in “hidden requirements”. For example, when the facilitator comes around to verify the 2D shapes, she could say, “That is indeed a square, but I forgot to tell you, all the straws in the square must be blue.” This would simulate a real-life project.

This isn’t the quick game I envisioned, but it has potential, and I think it’s worth trying out. Thanks to everyone who helped me, I’d never have thought of this on my own! Collaboration rules!

I’m looking forward to Agile Coach Camp and more learning, insights, and friends.

My review of Uncle Bob Martin’s The Clean Coder is up on my Techwell blog. If you’ve read the book, I’d love to hear your thoughts on it. If you haven’t read the book, please do so!

On March 24, I facilitated a workshop at Agilistry Studios in Pleasanton, CA, on Learning for Testers. 19 practitioners from the Bay Area got together to consider how, as testers, we can learn ways to contribute more to our teams, as well as raising the bar for our profession. I’d like to share some of the ideas generated by this engaging group!

Why We Should Learn

We started out by considering good reasons that testers should learn. Participants self-organized into groups, brainstormed ideas, and each group chose their top three ideas to share. Some of the items surprised me. One reason to learn was “to reduce stress”. I asked the group to elaborate. They pointed out that it is stressful if you aren’t sure whether you have the appropriate skills to do your job. That is so true, I have felt that stress before!

Another category of reasons that resonated with me was “to have fun” and “not to be bored and have ADD”. Finding joy in our work should be our highest priority IMO!

Rather than take up room on this page, I invite you to see the photos of the actual results on my Picasa site.

What We Should Learn

I love the Bay Area, it is truly a crucible of software creativity. It is no surprise, therefore, that the ideas of what to learn were surprising to me.

“Knowing when to stop” – wow, so true. Any good tester can find things to test forever. When have we achieved the “minimum”? What is “enough”? Given that in real life, we have time and resource limitations, this is a crucial skill.

“How to invent test ideas” – cool!

“Deciding what is most important to test” – that kind of ties in with “Knowing when to stop”, I think. Knowing how to analyze risks, learning customer and user priorities, these are necessary skills for testers.

I was glad to see “thinking skills” were a priority, such as: Communication, Integrity, How to Teach. Integrity is particularly interesting to me. It’s essential, but how do we learn it? How do we teach it? Comments, please!

Another interesting skill to learn was the “Elevator Pitch”. If you can describe what you do in under a minute, you must really understand it. This exercise produced many intriguing skills – please check out the photos of the sticky notes.

How To Learn These Things?

I think the most innovative ideas in this workshop surfaced during the “How To” brainstorming.

Consider this: “Note your assumptions. Later, compare what happens to your assumptions. When you stop, note your reasons for stopping. Mindfulness.” I don’t know about you, but I am going to try this.

Journalism class, to learn how to make elevator pitches – what a great idea! We have to go outside our profession to get skills that will help us do our best work.

Risk taking – set out to fail! This takes a lot of courage, but failure is a great way to learn, so why not?

And finally, my favorite, “Learn by doing”. Isn’t that the best way? But to learn, we need time. If we’re always focused on meeting deadlines, we won’t absorb any learning.

Make some room today for learning. Your team has the best solutions to your problems. You just need to take the time to talk about them and think of small experiments (as Linda Rising says) to address them.

My colleague and co-author Janet Gregory and I have a new article in this month’s Better Software about Learning for Testers, with some additional material on Techwell.com. We’d love to know what you think, please comment!

I’m doing two tutorials (including one together with Janet Gregory) and a track session at StarEast 2011 (see my News and Events page for more details or click to see the brochure). If you use the discount code SKWS you can get $200 off, and if you book before March 4 you also get Early Bird pricing which is another $400 off. Take a look at the program, there will be a lot of great practitioners there this year. Not only are there some valuable sessions, you’ll learn a lot from the informal activities with fellow participants.

I’ve been wanting to try Weekend Testing for ages, but I’m usually swamped on the weekends. The European chapter that does Weeknight Testing (@WNTesting on Twitter; hashtag #WNTesting) works great for me because the time ends up being during my lunchtime. I tried it for the first time today.

Our mission was to do functional testing on TinyURL. The plan was to test for an hour, then debrief & discuss. I paired with Darren McMillan and we started working on a mind map in MindMeister. At the same time, I was trying things and noting it down in TextWrangler. We tried happy path tests, negative tests, boundary tests, crazy urls, trying in different browsers. I tried out features such as custom URLs and preview, both of which were not as intuitive as I hoped but this was meant to be functional testing.  Darren had ideas I didn’t think of, such as URLs with accents on the letters.

The debrief was interesting, other people thought of such good approaches. One thing I hadn’t thought of was urls in other character sets. Things like turning Javascript on and off did not even occur to me. People used tools and heuristics that were new to me. This was fun, and a super way to get ideas for good ways to do exploratory testing. I intend to keep on joining Weeknight and Weekend tester sessions as often as possible!

Here is a scaled-down picture of our mind map, you can click on the link higher up to get the full version.

Mind Map for Weeknight Testing Session

I was so pleased when my copy of Naomi Karten’s Presentation Skills for Technical Professionals arrived the day before I left for Agile Testing Days in Berlin. I started presenting at conferences in the late 80s, and have presented at many conferences in this millenium. I’ve worked hard to improve as a speaker, facilitator and coach, I’ve taken lots of public speaking and presenting classes, I study the evaluations from each session’s participants, I read blog posts about how to present. But behind my conference persona, I am an extremely shy person, so it’s always a fight.

I read Naomi’s book on the flight to Berlin. It’s an easy and entertaining read, and I learned a lot. One gem was the advice to pause occasionally – when finishing a key point, when inviting questions, before advancing to the next slide. It gives participants time to let the information sink in, and to formulate questions. I talk WAY too fast, so this was a good tip for me. I remembered many times during my Agile Testing Days tutorial and keynote to pause for a moment, and that helped me remember to speak more slowly and clearly. (I still got evaluations that said I was hard to understand, but I hope I was better than in the past).

Another important takeaway was to set up ground rules at the beginning of the session. I always do this, but I liked the suggestion for managing time, to say to the group, “If we’re running short on time, would it be alright if I discontinue some discussions in the interest of moving on?” By framing a ground rule as a question, you get buy-in from the group.

Building rapport with the audience before the session starts was another good tip. I’ve done this in the past, but because I am such an introvert, I didn’t do it enough. I made a conscious effort in Berlin to engage individuals who arrived early and ask about their experiences on the topic I was about to present. When I got nervous later, I could look at the people I’d talked to ahead of time and felt I was in the company of friendly people.

The chapters on logistical preparations and the “presenter survival kit” contained many good reminders of things I know, but sometimes get sloppy about. For example, I had gotten out of the habit of putting my slides on a USB flash drive, in the event my MacBook dies and I have to borrow a laptop. I always think “I can download it if I need it”, but many conference rooms don’t have internet connectivity.

I think I’m good about avoiding PowerPoint abuse – my slides aren’t flashy, but they are also not overcrowded with information, and I don’t read them – but the chapter on using (and not mis-using) Powerpoint has good pointers (no pun intended). I also tell a lot of stories, so I was glad to read that Naomi recommends this practice and explains how to craft a story.

There is lots more great information about all aspects of presenting in this book. I highly recommend it to everyone who ever has to make a presentation – whether you only rarely have to present to fellow employees, or speak frequently at conferences. It has good reminders for experienced speakers, plus some nuggets you might not have thought of. If you’re new to presenting or nervous about it, following the instructions in this book will give you much more confidence and let you enjoy the experience instead of dreading it.

My Agile Testing Days tutorial is almost full, so my motivation here is not to advertise it, but to invite you to meet one of my donkeys, Ernest. I tried to make the video with both Ernest and Chester, but it was very windy outdoors that day and Chester was fidgety, we couldn’t get a good video. My friend Anna suggested taking Ernest indoors to do the video, so we went in the living room and it worked just fine. It’s short, please enjoy!

Podcasts are a nice way to learn about new topics, pick up new ideas and hear the experiences of other testers and agile practitioners. I highly recommend the Testing Podcast site for informative interviews with a wide range of testing practitioners.

This interview with Michael Kircher of Software Engineering Radio was posted in June 2010 and can be found on testingpodcast.com as well, along with some other podcasts I’ve done in the past. Michael and I cover several topics ranging from the role of the tester in agile teams, over test automation strategy and regression testing, to continuous integration. I really enjoyed it because we got to talk for over an hour (though the podcast is not that long.)

InfoQ just published an article I wrote to try to inspire more testers to grow their skills. It begins:

The software industry is changing fast. More and more teams put testing up front and center; they use tests to drive development. New and improved automated test frameworks and drivers burst onto the scene every month. Teams with more automated regression suites need testers with sharp exploratory testing skills. But most people do not learn the needed skills in university: where will these testers come from? Read more…

There are so many test frameworks, drivers and other tools out there I want to try. For example, Selenesse has been at the top of my list of things to try for months (and I’ll get to it sometime soon!) However, I couldn’t resist the offer from Pekka Klarck, one of the Robot Framework contributors, to give me a live one-on-one demo of Robot Framework a couple of weeks ago. This weekend, I finally had time to try to write my first test (really, to finish up a test that Pekka had started for me).

My first test is below. I always struggle mightily when I learn some new tool or language, and this was no exception. (Apparently my more-geeky friends also struggle with new things, but they don’t whine publicly about it like I do). The user doc for RF leaves a bit to be desired from a non-programmer perspective. However, they are actively improving it. With much help from Pekka (and suggestions from many in the Twitterverse who also use RF), I have gotten over this first beginner hump, I can see lots of possibilities.

You can write RF tests in various formats, including HTML tables. I like the plain text format, because to me, simple is good. It makes the tests more amenable to version control, because you can easily diff versions to see what has changed. If you try that with html table tests you’ll have lots of noise.

I love the flexibility of this tool. I am trying it out with the RF Selenium libraries, but you can use it with a variety of tools, including tools to test non-Web apps such as Java Swing. There’s a lot of potential there.

I like the fact that you can define whatever “keywords” you want, so you can create your own domain-specific language and the test can document itself and the code that it is testing. The inline-documentation aspect is also one of my favorite features of FitNesse.

My team is pretty happy with our current tools: FitNesse for testing behind the GUI, Canoo WebTest for GUI regression tests, and Ruby/Watir scripts to help with exploratory testing. We’ve long wanted to try Selenium, though, and RF would give us an easy way to do that. We’re always experimenting, and an experiment with RF will tell us whether there’s value in adopting it.

For myself, I think RF will be useful in my public presentations and classes. I’m always looking for ways to teach good test automation design, and I think I can do this fairly easily with RF. I’ve seen Dale Emery and Elisabeth Hendrickson do good demos with RF. I’ve also seen Antony Marcano, Andy Palmer and Gokjo Adzic do good demos with FitNesse, so I’m not saying one is better for this purpose than the other!

Here’s my test. I also copied it in below, though the spacing might be wacky there. I put comments in for myself that might help you, too. Download the RF-Selenium library demo and try it for yourself. If you have any issues I am glad to try to help. It would help me learn, too!

—-

lisas_first_test.txt

# new line and 2 spaces are cell delimiters.
# the asterisks have to start in the first col
# Look at the selenium keywords in http://code.google.com/p/robotframework-seleniumlibrary/wiki/LibraryDocumentation
# Look at the quick start guide for more http://code.google.com/p/robotframework/wiki/QuickStartGuide
Actually you don’t even need the # if you type up above the first table. Tables can be in any order. ‘*** Test Cases***’ is an example of a table.
Run it with ./rundemo.py lisas_first_test.txt
To start the server for the app under test manually, python httpyserver.py start

*** Test Cases ***

invalid account
navigate to the login page
type in username  invalid
type in password  xxx
click submit
verify the invalid account error message

*** Keywords ***

navigate to the login page
log  hello, world!
open browser  ${LOGIN PAGE}  ${BROWSER}
title should be  Login Page
${title} =  Get Title
should start with  ${title}  Login

type in username  [Arguments]  ${username}
input text  username_field  ${username}

type in password  [Arguments]  ${password}
input text  password_field  ${password}

click submit
Click Button  login_button

verify the invalid account error message
Title should be  Error Page
Page should contain  Invalid user name and/or password

*** Settings ***
Library  SeleniumLibrary
Test Teardown     close browser

*** Variable ***
${LOGIN PAGE}   http://localhost:7272
${BROWSER}      firefox