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.

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!

This past Saturday I was fortunate to be one of the 60 people enrolled for the largest Code Retreat ever, Code Retreat Boulder, facilitated by Corey Haines and Chad Fowler, organized by Prakash Murthy. This was my first Code Retreat, though I’ve worked on teams practicing TDD, pair programming, and good design practices for more than ten years.

I was the only tester attending, and as I had feared, I was somewhat out of my depth. Nevertheless, I write automated tests, and I need to apply the same design basics to those as we do to production code. The past couple of years, I’ve tried to think of ways to help testers learn those principles, and written articles such as “An Intro to Test Design” in the Testing Planet. One goal of Code Retreat is stretching yourself, making ugly messes and not worrying about it even though our goal is perfection. I was definitely stretched way beyond my comfort zone!

Corey explained the basics we should practice:

1. Tests pass – J.B. Rainsberger says this is “like breathing”.
2. Don’t Repeat Yourself, keep code DRY
3. Tests and code reveal intent – name things well
4. Small – work in tiny increments.

The day was divided into 45-minute pairing sessions; we switched pairs each time. We wore name tags that indicated our programming language preferences. At the end of each session, we had to delete our code, stand up, and debrief for a few minutes about what we learned and what to try next. We also had a long lunch break (with delicious food!) The coding problem to solve was Conway’s Game of Life. As I dislike both math and puzzles, this scared me.

Mike Clark generously offered to pair with me in the first session. I’ve known Mike for ten years and he’s a TDD guru. We used RSpec and TextMate, both new to me (at work, we use test::unit with Ruby, and I use IntelliJ Idea). It was so natural for Mike to start writing a tiny test, then a tiny bit of code, which he put in the same file to start off – quite efficient. He had brought graph paper, which was handy for writing down examples of what a Game of Life grid would look like. We immediately set about creating and testing a board of cells. Corey came around to look at what we’d done, and commented that we should try to avoid numbers and X/Y coordinates. Hmmm. He mentioned encapsulation, which I understood to mean we don’t need to know about cells, only the board.

Apparently most everyone had started out creating a grid and using X/Y coordinates. For the second session, I paired with Erika Bricey, who works at Rally Software. We decided to follow Corey’s advice to start with the rules, to focus on the names for the methods, and whether the methods are doing too much. Corey mentioned that a class with plural name is a collection of other things. Erika and I had some good ideas on how to approach the problem, but for sure I couldn’t turn those into code, and Erika struggled too. Erika also used RSpec, but she worked in Eclipse.

Seeing our frustration, Corey and Chad suggested we less skilled persons find highly skilled pairs. So I waylaid Marty Haught, a test-obsessed programmer I’ve been wanting to talk to. He went along with my desire to focus on rules and on the names of things. For example, we started out with a module called “alive”, for cells that are alive. Later we needed to have dead cells, so we renamed that to “remain_alive” and the other module was called “dead_cell”. We wrote tests and code for most of the rules. We tried to follow Corey’s advice that “anytime you need to DO something, ASK another object”. For example, to find out if a cell is alive, ask “How many neighbors do I have?” and that will invoke an object that says “Here’s my number of neighbors, am I alive?”

Corey told us that if every time you have to make a decision, you ask someone(thing) else, you end up with no “if” statements. He challenged us to see how far we could go before we had to have a number. He noted that there are two parts to the rule: the hard-coded rule such as “Any live cell with fewer than two live neighbours dies” also states the spirit of the rule: “as if caused by under-population”. Aha! We should write our code in terms of under- and over-population instead of hard-coded boundaries.

My first pair after lunch, Anthony, used MacVim. I’m an old fan of Vim, but hadn’t seen MacVim. We talked about the fact that the grid is infinite, and decided to see if we could get information about the neighbors of any one cell, working with relative numbers. Anthony was pretty sharp at figuring out how to do this, and we made a lot of progress in the 45 minutes. Other pairs tried starting with the outside abstraction and working in.

I was getting tired and didn’t take as many notes in the afternoon – it was all I could do to keep up with what my pair was doing. I had low expectations with regard to my Ruby coding knowledge, but I learned how much I don’t know! For the last session, I was the kid who didn’t get picked for the softball team, I didn’t have a pair, so I observed Rob Park and his pair working in Java. I work on a Java team. It was interesting to see the immediate contrast of working in Ruby vs. Java for the same coding problems. Java looked much slower and more cumbersome to me.

We finished with a closing circle where each person stated what we learned, what surprised us, and what we’ll do differently back at work on Monday. Many of the participants were new to pairing and TDD. I’m not, but it reinforced the value I’ve gotten by learning through pairing with a programmer. I learn more about code design in an hour of pairing than from days of reading books. I plan to be more diligent in applying good design principles to automated test code – for example, pay more attention to using good names. I won’t just take the first solution that occurs to me, I’ll experiment with different approaches. Let’s see if I achieve that goal!

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.

The Testing Planet from  the Software Testing Club has indeed landed! It is chock full of excellent articles about testing, both technical and cultural. Just a sample of the titles: “Yes, It’s Personal”, “Context-driven Jumping”, “Testing & Creativity”, “Weekend Testing Fun”. I am extremely proud that my article, an introduction to test automation design, is on the front page!

Though The Testing Planet is available digitally, I urge you to subscribe to the print version. 1) it is way more fun and convenient (at least for us folks who prefer an actual newspaper with our morning tea), 2) it supports the magazine, and we need to support it and keep it going! The Software Testing Club rocks, it’s a great way to meet and exchange ideas with testers all over the planet. Give a little back to your testing community by supporting The Testing Planet.

Methods and Tools

I wrote a tool review of FitNesse for the Summer issue of Methods and Tools magazine. Please let me know if you have any questions about it.

Recently I tweeted about a fishbowl we conducted at the Business Analysis Workshop of the Better Software conference. Some tweeps weren’t familiar with the fishbowl format, so I thought I’d explain how I like to do fishbowls.

Fishbowl Discussion at BA Workshop, Better Software conference

Fishbowls are a good format for a panel discussion where you want to involve the whole audience, as well as a panel of pre-selected experts.

Put some chairs in the center of the room. They can face each other or, if the room isn’t set up for everyone to sit in a circle, face the audience. The number of chairs depends on the size of your audience. An average for a group of 20 people is five chairs. You’ll start with only four of the chairs occupied. Arrange the rest of the chairs in the room in a circle or semi-circle around the fishbowl.

If you have pre-selected panelists, have them sit down in the chairs leaving one chair empty. The rules are simple: anyone in the room can come sit in the empty chair. When that happens, someone else on the panel has to get up and return to the audience. Panelists may come and go by sitting in the empty chair whenever they want to join the debate.

The audience doesn’t participate actively in the discussion. You have to sit in the empty chair to start contributing to the discussion. The beauty of the fishbowl is that the audience gets to hear a variety of viewpoints, and anyone in the audience can choose to participate.

I’ve used fishbowls for panel discussions of controversial topics. Jean Tabaka recently facilitated a “Kanban vs. Scrum” fishbowl debate at Better Software, and allowed people to contribute via Twitter, as well. I’ve also used them for workshops where the participants are trying to come up with new ideas about a topic. For example, I might use a fishbowl format for a workshop where we try to think of better ways for development teams to elicit requirements from their customers. For my starting panel, I might choose people such as Elisabeth Hendrickson, Antony Marcano, Gojko Adzic and Jennitta Andrea, who are recognized experts in using customer-facing tests to drive development. They’re bound to have some good experiences to relate. But there’d also be a roomful of practitioners who have their own ideas and experiences, and with a fishbowl format, we get to hear from everyone.

Try a fishbowl at your next local user group meeting. It’s a great way for everyone to contribute, and it produces lots of valuable ideas from a variety of viewpoints.

I’ve worked on four agile teams in the past nine years. Three were highly successful, especially the one I was on for the past 5.5 years. One never really made the transition, though we had a successful agile project. One of the successful ones involved a team of about 30 developers, and that’s the largest project I’ve been on up to now.

I could have happily worked with my previous team until I retire, but you know me, I cannot resist new opportunities. So now I’m on a small Scrum team – that is one of 28 Scrum teams at my new company! Yes, this company actually manages to have 28 teams, including some which provide infrastructure such as frameworks and deployment, working together to release a high-quality commercial software product four times a year.

Yeah, back in the day, XP was for little, co-located teams. “You can’t do shrink-wrapped software with XP” was just one of the many axioms I heard.

Now I work in an agile organization with about 140 developers, some (like me) in remote locations, delivering software both for Windows client and for a hosted solution. (I don’t know everything about it yet so sorry to sound vague!) If you had told me this five or ten years ago, I wouldn’t have been sure it could work.

Since my new 5-person team is a self-organizing Scrum team, we picked our own ScrumMaster, which ended up being me. I love being an uncertified ScrumMaster, and plan to delegate a lot, because I’m also committed to remaining a hands-on tester. I attended my first Scrum of Scrums (some attendees called it the “SoS” which I loved) on Friday. Each of the 28 ScrumMasters (some in the room, some on the phone) was called on to say if they had any impediments. This happened to be a release day, so I thought there might be lots of impediments, but most teams didn’t have any. Those that did got help right away. The meeting was over in 10 or 15 minutes.

Granted, not every team is high-performing, and some practices I’m used to are missing altogether. But think about it, a software development organization that large, which only implemented Scrum four years ago, able to coordinate and release critical value frequently, at a sustainable pace. That’s agile in anyone’s book.

Follow this space for my adventures as I enter a whole new world!

Are you a tester wondering what the heck you should be doing now that you’re suddenly on an agile team? Are you a manager of a new agile team puzzled at why the QA group refuses to cooperate with you? Are you an agile developer trying to figure out how to deliver the best possible software? If so, you might be interested in the three-day agile testing course that Janet Gregory and I are developing. We’re offering this course in partnership with LeanDog in Cleveland and with Program Utvikling in Norway, and will be offering it in other locales as well – please contact me if you’re interested.

Here’s a course description:

Over three days, we put theory into action through a variety of exercises. This course teaches testers how to fit into agile projects, contribute to the whole team and overcome common cultural and logistical obstacles in transitioning to an agile development process. It explains the values and principles that help testers adopt an agile testing mindset and how to accomplish traditional testing processes, such as defect tracking, metrics, audits, and conforming to quality models. Students will learn how to complete testing activities in short iterations, and how testers contribute on a daily basis during each iteration and release cycle. Through interactive exercises and group discussions, participants will discover good strategies for driving development with both executable and manual tests. The course is filled with real-life examples of the many ways agile testers add value.