Agile Testing: A Practical Guide for Testers and Agile Teams

The product owner sketches out the desired UI on the whiteboard. There’s a “delete” checkbox next to each item and an “update cart” button. The user can select one or more items and click the button to remove the items. The high-level tests might be:

When the user clicks the delete checkbox next to the item and clicks the “update cart” button, the page refreshes showing the item is no longer in the cart.

When the user clicks the delete checkboxes next to every item in the cart and clicks the “update cart” button, the page refreshes showing an empty cart. (This will generate questions—should the user be directed to another page? Should a “keep shopping” button display?)

When the user clicks the “update cart” button without checking an item for delete, the page is refreshed and nothing is removed from the cart.

Ask your customers to write down examples and high-level test cases before the iteration. This can help them think through the stories more and help define their conditions of satisfaction. It also helps them identify which features are critical, and which might be able to wait. It also helps to define when the story is done and manage expectations among the team.

Figure 16-4 shows a sample mock-up, where the product owner marked changes on the existing page. Be careful about using an existing screenshot from an old system, because you will run the risk of having a new system look exactly like the old one even if that is not what you wanted.

Figure 16-4 Sample customer mock-up

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