Agile Testing: A Practical Guide for Testers and Agile Teams

Potential Downsides to Advance Preparation

There’s a risk to “working ahead.” You could spend time learning more details about a feature only to have the business people re-prioritize at the last minute and put that feature off indefinitely. Invest preparation time when it’s appropriate. When you know you have a complex theme or story coming up, and it has a hard deadline such as Lisa’s team had with the statement story, consider spending some time up front checking out different viewpoints. The only reason to discuss stories in advance is to save time during iteration planning and during development. A deeper understanding of the feature behavior can speed up testing and coding, and can help make sure you deliver the right functionality.

If your situation is so dynamic that stories might be re-prioritized the day that the iteration starts, it isn’t worth trying to do this planning. Instead, make sure you budget time for these discussions during your planning meeting.

Advance Clarity

Lisa’s product owner, Steve Perkins, came up with the term “advance clarity.” Different parts of each organization have different priorities and agendas. For example, Business Development is looking for new features to attract new business, while Operations is prioritizing features that would reduce the number of phone calls from users. The development team tries to understand the range of business needs and get a feel for each individual’s job.

With many different agendas, someone needs to decide what stories should be implemented in the next iteration. Because there are many ways to implement any given story, someone has to decide the specific requirements and capture them in the form of examples, conditions of satisfaction, and test cases. Steve gets everyone together to agree on the value they want from each story, and to provide “advance clarity.”

Customers Speak with One Voice

Scrum provides the helpful role of the product owner to help all the customers “Speak with One Voice.” Whether or not you’re on a Scrum team, find some way to help your customers agree on the priority of the stories and how the components of each story ought to be implemented. Management support is crucial, because any person in this role needs time and authority to get everyone on the same page.

Other teams use business analysts to help flesh out the stories before the next iteration. In one organization Janet worked with, the customers were not available full-time to answer questions, but each team had a business analyst that worked with the customers to flesh out the requirements before the iteration planning meeting. If there were any questions that she could not answer at the meeting, the team either called the customer directly or the analyst followed up immediately after the meeting.

As a tester, you want to sit in on story writing and prioritization meetings. Ask questions that help the customers focus on the core functionality, the critical business value they need. Help participants stay focused on concrete examples that crystallize the meaning of the stories. In meetings that involve multiple customers, it is critical to have a strong facilitator and a method for determining consensus.

As with code, stories are best if they have the bare minimum. For example, an Internet shopping cart needs some way to delete unwanted items, but the ability to move items from the cart to a “save for later” list can probably wait. It may be helpful to talk about this before the iteration, so that the team is clear on what tasks need to be planned. Focus on the simplest thing first and use an example to make it clear.

Get All Viewpoints

Getting requirements from different customers for a story, each of whom has a different agenda, might create chaos. That’s why it’s essential for someone on the customer team to get consensus and coordinate all points of view. This doesn’t mean we shouldn’t get input from different customers. As a tester, you’re considering each story from multiple points of view. It helps to know what the story means to people in different roles.

Lisa’s Story

When my company decided to redesign the retirement plan participants’ quarterly account statements, different people on the business side wanted changes for different reasons. The plan administrators wanted a clearly understandable layout that would minimize the number of calls from confused participants to customer support.

For example, they wanted the statement to show the date and amount of the participant’s most recent contribution. This helps the participant know whether her employer is late in posting contributions to the accounts. Business development wanted jazzy new features that they could sell to potential customers, such as graphs of performance by fund category. Our legal person needed some new text and data on the statement to satisfy federal regulations.