Agile Testing: A Practical Guide for Testers and Agile Teams

Agile teams try to solve their own problems and set guidelines to help themselves improve. Action items aimed at one problem may help with others. When Lisa’s team had trouble finishing stories and getting them tested during each iteration, it came up with various rules over the course of a few retrospectives:

Finish high-level test cases for all stories by the fourth day of the iteration.

Deliver one story to test by the fourth day of the iteration.

Focus on finishing one story at a time.

100% of features must be checked in by close of business on the next-to-last day of the iteration.

These rules did more than help the team finish testing tasks. They facilitated a flow and rhythm that helped the team work at a steady, sustainable pace over the course of each iteration.

Begin the next retrospective meeting by reviewing the action items to see what items were beneficial. Lisa’s team puts happy, sad, or neutral faces next to items to denote whether the team tried them and found them successful. The team should figure out the reasons behind any sad faces. Were some items simply forgotten? Did time constraints keep the team from trying a new activity? Did it just seem to be less of a good idea later? These discussions might lead to changing the improvement item or evolving it into a new one.

When the actions for improvement become a habit to the team, they no longer need to be written on the “stop, start, and continue” list. “Start” items that work well may be moved to the “Continue” column. Some ideas don’t work, or prove to be unnecessary, and those can also be taken off the list for the next iteration.

Refer to your ideas for improvement and action items during the iteration. Post them in a location (on a wall or online) where everyone sees them often. Lisa’s team sometimes goes through the list during a mid-iteration stand-up meeting. If you think of new improvement ideas during the iteration, write them down, possibly even on the existing list, so you won’t forget for the next iteration.

It’s a good idea to keep track of things that get in your way throughout the iteration. Keep an impediment backlog on some big visible chart. Talk about the impediments in each iteration, and write task cards or take action to eliminate them.

An Approach to Process Improvement

Rafael Santos, VP of Software Development and Chief ScrumMaster at Ultimate Software, and Jason Holzer, the Chief PSR (Performance, Security, Reliability) Architect, explained to us that their teams found retrospectives that used the “stop, start, and continue” model ineffective. They made “stop, start, and continue” lists, but those didn’t provide enough focus to address issues.

Instead, the ScrumMaster kept an impediment backlog, and the team found that worked better than retrospectives. Impediments may be related to testing or tools.

They also do value stream mapping to find the biggest “wait time,” and use the “five whys” from Toyota to understand which impediment is the biggest or which constraint needs to be addressed.

See the bibliography for good resources for lean development practices.

One example shared was that in a team with three programmers and one tester, the biggest problem was a testing bottleneck. Rafael asked the team what the tester does and wrote those items on a whiteboard. Then he asked the programmers which of those things on the board they couldn’t do. There was only one item they felt they couldn’t handle. This helped the programmers understand how everyone on the development team, not only the testers, could be responsible for testing tasks. This was a highly effective exercise.

Creative approaches like this help new agile teams tackle difficult testing challenges. Retrospectives are a good environment for experimenting.

Use retrospectives as an opportunity to raise testing-related issues and get the whole team thinking about possible solutions. We’ve been pleasantly surprised with the innovative ideas that come out of an entire team focusing on how to improve the way it works.

Celebrate Successes

Agile development practices tend to moderate the highs and lows that exist in more traditional or chaotic processes. If your waterfall team finally manages to push a release out the door after a year-long cycle ending in a two-month stressful fix-and-test cycle, everyone may be ready to celebrate the event with a big party—or they might just collapse for a couple of weeks. Agile teams that release every two weeks tend to stay in their normal coding and testing groove, starting on the next set of stories after drawing just enough breath to hold an iteration review and retrospective. This is nice, but you know what they say about all work and no play.