Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Mock-ups are essential for stories involving the UI or a report. Ask your customers to draw up their ideas about how the page should look. Share these ideas with the team. One idea is to scan them in and upload them on the wiki so everyone has access. Use those as a starting point and do more paper prototypes, or draw them on the whiteboard. These can be photographed and uploaded for remote team members to see.

Test Strategies

As you learn about the stories for the next iteration, think about how to approach testing them. Do they present any special automation challenge? Are any new tools needed?

Lisa’s Story

Recently, our company needed to replace the voice response unit hardware and interactive voice interface software. A contractor was to provide the software to operate the voice application, but it needed to interact via stored procedures with the database.

This was a big departure from any software we’d worked on before, so it was helpful to have an extra day to research how other teams have tested this type of application before the first iteration planning that involved a story related to this project. During the iteration planning session, we were able to write tasks that were pertinent to the testing needed and give better estimates.

—Lisa

When your team embarks on a new type of software, you may decide to do a development spike to see what you can learn about how to develop it. At the same time, try a test spike to help make sure you’ll know how to drive the development with tests and how to test the resulting software. If a major new epic or feature is coming up, write some cards to research it and hold brainstorming meetings an iteration or two in advance. That helps you know what stories and tasks to plan when you actually start coding. One idea is to have a “scout” team that looks at what technical solutions might work for upcoming stories or themes.

Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” Chapter 10, “Business-Facing Tests that Critique the Product,” and Chapter 11, “Critiquing the Product Using Technology-Facing Tests,” provide examples of tools for different types of testing.

Prioritize Defects

In our ideal world, we want zero defects at the end of each iteration and definitely at the end of the release. However, we recognize that we don’t live in an ideal world. Sometimes we have legacy system defects to worry about, and sometimes fixing a defect is just not high enough value for the business to fix. What happens to these defects? We’ll talk about strategies in Chapter 18, “Coding and Testing,” but for now, let’s just consider that we have defects to deal with.

Before the next iteration is an ideal time to review outstanding issues with the customer and triage the value of fixing versus leaving them in the system. Those that are deemed necessary to be fixed should be scheduled into the next iteration.

Resources

Another thing to double-check before the iteration is whether your team has all the resources you need to complete any high-risk stories. Do you need any experts who are shared with other projects? For example, you may need a security expert if one of the stories poses a security risk or is for a security feature. If load testing will be done, you may need to have a special tool, or have help from a load testing specialist from another team, or even a vendor who provides load testing services. This is your last chance to plan ahead.

Summary

Your team may or may not need to do any preparation in advance of an iteration. Because priorities change fast in agile development, you don’t want to waste time planning stories that may be postponed. However, if you’re about to implement some new technology, embark on a complex new theme, hope to save time in iteration planning, or your team is divided into different locations, you might find some up-front planning and research to be productive. As a tester, you can do the following:

Help the customers achieve “advance clarity”—consensus on the desired behavior of each story—by asking questions and getting examples.

Be proactive, learn about complex stories in advance of the iteration, and make sure they’re sized correctly.

You don’t always need advance preparation to be able to hit the ground running in the next iteration. Don’t do any preparation that doesn’t save time during the iteration or ensure more success at meeting customer requirements.

Coordinate between different locations and facilitate communication. There are many tools to help with this.

Obtain examples to help illustrate each story.

Develop test strategies in advance of the next iteration for new and unusual features.

Triage and prioritize existing defects to determine whether any should be scheduled for the next iteration.

Determine whether any necessary testing resources not currently at hand need to be lined up for the next iteration.

Chapter 17 Iteration Kickoff

Agile testers play an essential role during iteration planning, helping to plan testing and development tasks. As the iteration gets under way, testers actively collaborate with customers and developers, writing the high-level tests that help guide development, eliciting and illustrating examples, making sure stories are testable. Let’s take a closer look at the agile tester’s activities at the beginning of each iteration .

Iteration Planning

Most teams kick off their new iteration with a planning session. This might be preceded by a retrospective, or “lessons learned” session, to look back to see what worked well and what didn’t in the previous iteration. Although the retrospective’s action items or “start, stop, continue” suggestions will affect the iteration that’s about to start, we’ll talk about the retrospective as an end-of-iteration activity in Chapter 19, “Wrap Up the Iteration.”

While planning the work for the iteration, the development team discusses one story at a time, writing and estimating all of the tasks needed to implement that story. If you’ve done some work ahead of time to prepare for the iteration, this planning session will likely go fairly quickly.

Teams new to agile development often need a lot of time for their iteration planning sessions. Iteration planning often took a whole day when Lisa’s team first started out. Now they are done in two or three hours, which includes time for the retrospective. Lisa’s team uses a projector to display user acceptance test cases and conditions of satisfaction from their wiki so that everyone on the team can see them. They also project their online story board tool, where they write the task cards. Another traditional component of their planning meetings is a plate of treats that they take turns providing. Figure 17-1 shows an iteration planning meeting in progress.