Agile Testing: A Practical Guide for Testers and Agile Teams

There are conditions of satisfaction for the whole release as well as for each feature or story. Acceptance tests help define the story acceptance. Your development team can’t successfully deliver what the business wants unless conditions of satisfaction for a story are agreed to up front. The customer team needs to “speak with one voice.” If you’re getting different requirements from different stakeholders, you might need to push back and put off the story until you have a firm list of business satisfaction conditions. Ask the customer representative to provide a minimum amount of information on each story so that you can start every iteration with a productive conversation.

The best way to understand the customer team’s requirements is to talk with the customers face to face. Because everyone struggles with “requirements,” there are tools to help the customer team work through each story. Conditions of satisfaction should include not only the features that the story delivers but also the impacts on the larger system.

Lisa’s product owner uses a checklist format to sort out issues such as:

Business satisfaction conditions

Impact on existing functions such as the website, documents, invoices, forms, or reports

Legal considerations

The impact on regularly scheduled processes

References to mock-ups for UI stories

Help text, or who will provide it

Test cases

Data migration (as appropriate)

Internal communication that needs to happen

External communication to business partners and vendors

The product owner uses a template to put this information on the team’s wiki so that it can be used as team members learn about the stories and start writing tests.

Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” includes example checklists as well as other tools for expressing requirements.

These conditions are based on key assumptions and decisions made by the customer team for a story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. Discussing conditions of satisfaction helps identify risky assumptions and increases the team’s confidence in writing and correctly estimating all of the tasks that are needed to complete the story.

Ripple Effects

In agile development, we focus on one story at a time. Each story is usually a small component of the overall application, but it might have a big ripple effect. A new story drops like a little stone into the application water, and we might not think about what the resulting waves might run into. It’s easy to lose track of the big picture when we’re focusing on a small number of stories in each iteration.

Lisa’s team finds it helpful to make a list of all of the parts of the system that might be affected by a story. The team can check each “test point” to see what requirements and test cases it might generate. A small and innocent story might have a wide-ranging impact, and each part of the application that it touches might present another level of complexity. You need to be aware of all the potential impacts of any code change. Making a list is a good place to start. In the first few days of the iteration, the team can research and analyze affected areas further and see whether any more task cards are needed to cover them all.

Janet’s Story

In one project I was on, we used a simple spreadsheet that listed all of the high-level functionality of the application under test. During release planning, and at the start of each new iteration, we reviewed the list and thought about how the new or changing functionality would affect those areas. That became the starting point for determining what level of testing needed to be done in each functional area. This impact analysis was in addition to the actual story testing and enabled our team to see the big picture and the impact of the changes to the rest of the system.

—Janet

Stories that look small but that impact unexpected areas of the system can come back to bite you. If your team forgets to consider all dependencies, and if the new code intersects with existing functionality, your story might take much longer than planned to finish. Make sure your story tests include the less obvious fallout from implementing the new functionality.

Chapter 16, “Hit the Ground Running,” and Chapter 17, “Iteration Kickoff,” give examples of when and how teams can plan customer tests and explore the wider impact of each story.

Take time to identify the central value each story provides and figure out an incremental approach to developing it. Plan small increments of writing tests, writing code, and testing the code some more. This way, your Quadrant 2 tests ensure you’ll deliver the minimum value as planned.

Thin Slices, Small Chunks