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

—Lisa

These stories show that a few questions up front might save time during the iteration that could be spent figuring out what to do with new discoveries. However, we recognize that not all discoveries can be found early. For example, on the first story, a simple question about statement size may have prevented last-minute confusion about how to handle four-page statements, but the inaccurate address issue may not have been considered until it was being coded or tested.

We know there will always be discoveries along the way, but if we can catch the big “gotchas” first, that will help the team work as effectively as possible.

Geographically Dispersed 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

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