Agile Testing: A Practical Guide for Testers and Agile Teams

Some preparation for the next iteration may be useful for teams that are split across different locations. Teams that are distributed in multiple locations may do their iteration planning by conference call, online meeting, or teleconference. One practice, which a team of Lisa’s used, is to assign each team a subset of the upcoming stories and have them write task cards in advance. During the planning meeting, everyone can review all the task cards and make changes as needed. The up-front work enhances communication, makes the stories and tasks visible to everyone, and speeds up the planning process.

Of course, this assumes that the team is using an electronic story or task board. Lisa’s team uses Thoughtwork’s Mingle, but there are many other products out there that serve this purpose.

Coping with Geographic Diversity

We talked to a team we know at a software company that has customers, developers, and testers spread all over the globe. Not only are the customers far away from the technical team but they don’t have bandwidth to be available to answer the development team’s questions. Instead, the team relies on functional analysts who understand both the business side of the application at a detailed level and the technical implementation of the software. These functional analysts act as liaisons between the business and technical teams.

Patrick Fleisch and Apurva Chandra are consultants who were working with this company and served as functional analysts on a project to develop web-based entitlement software, because they are experts in this domain. They traveled between locations to facilitate communication between stakeholders and developers.

The functional analysts worked in advance of the iteration, sizing and getting stories ready to size, helping the technical team to understand the stories. They entered stories into an online tool and built on them by defining test cases, edge conditions, and other information that helped the technical team understand the story. They documented high-level functionality on a wiki aimed at the business users.

Apurva and Patrick played a key role in making the decisions that the technical team needed to get started with the new stories. Their deep business and technical understanding allowed them to provide the team with requirements they needed to get coding, because the actual customers weren’t available to them. David Reed, a tester and automation engineer, told us how he relied on Apurva and Patrick for the information he needed to perform and automate tests. While agile principles say to collaborate closely with the customer, in some situations you have to be creative and find another way to get clear business requirements.

If customers aren’t readily available to answer questions and make decisions, other domain experts who are accessible at all times should be empowered to guide the team by determining priorities and expressing desired system behavior with examples. Testers and business analysts are often called upon to do these activities.

Examples

You may notice that we talk about examples in just about every chapter of this book. Examples are an effective way to learn about and illustrate desired (and undesired) functionality; it’s worth using them throughout your development cycle. Our motto was coined by Brian Marick: “An example would be handy right about now.” (See Figure 16-2.) Start your discussions about features and stories with a realistic example. The idea has taken off, so that at a recent workshop for functional testing we were discussing ideas around calling it “Example-Driven Development.”

Figure 16-2 Brian Marick’s example sticker

When Lisa’s team members meet with their product owner to talk about the next iteration, they ask him for examples of desired behavior for each story. This keeps the discussion at a concrete level and is a fast way to learn how the new features should work. Have a whiteboard handy while you do this, and start drawing. If some team members are in a distant location, consider using tools that allow everyone to see whiteboard diagrams and participate in the discussion. Go through real examples with your customers or their proxies. As during release planning, consider different points of view: the business, end users, developers, and business partners. Unlike release planning, you are looking at far more detail because these are the stories you are planning for the next iteration.

Using examples, you can write high-level tests to flesh out each story a bit more. You may not need to do this before the iteration starts, but for complex stories, it can be a good idea to write at least one happy path and one negative path test case in advance. Let’s consider the story in Figure 16-3.

Figure 16-3 Story for deleting items from shopping cart