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

Don’t go overboard—if a pre-iteration activity doesn’t save time during the iteration, or help you do a better job, don’t do it before the iteration. Do what is appropriate for your team, and keep experimenting. Maybe you’ll do some of these activities after the iteration starts instead. Here are some ideas to think about that might help you “bake quality in” to your product.

Be Proactive

In Chapter 2, “Ten Principles of an Agile Tester,” we explained how agile testers have to shift their mind-set. Instead of waiting for work to come to us, we develop a proactive attitude where we get up and go look for ways to contribute. With the fast and constant pace of agile development, it’s easy to get immersed in the current iteration’s stories. We are so busy making sure we’ve covered the features with up-front tests, performing exploratory testing to be sure we’ve understood the business requirements, and automating adequate regression tests, it’s hard to think of anything else. However, it’s sometimes appropriate to take a bit of time to help our customers and our team prepare for the next iteration. When our team is about to break new ground, or work on complex and risky stories, some work before the iteration can help maximize our team’s velocity and minimize frustration.

We sure don’t want to spend all our time in meetings, or planning for stories that might be re-prioritized. However, if we can make our iteration planning go faster, and reduce the risk of the stories we’re about to undertake, it’s worth doing some research and brainstorming before we start the iteration.

Benefits

Working on stories in advance of the iteration may be especially useful for teams that are split across different geographic locations. By working ahead, there’s time to get information to everyone and give them a chance to give their input.

The problem is that we’re so busy during each short agile iteration that it’s hard to find time to meet about the next iteration’s stories, much less start writing test cases. If your iterations always go smoothly, with stories delivered incrementally and plenty of time to test, and the delivered software matches customer expectations, you may not need to take time to prepare in advance. If your team has trouble finishing stories, or ends up with big mismatches between actual and desired behavior of features, a little advance planning may save you time during the iteration.

Lisa’s Story

Our team used to feel we didn’t have time to plan in advance for the next iteration. After many experiences of misunderstanding stories and having them far exceed estimations, and finding most “bugs” were missed requirements, we decided to budget time in the iteration to start talking about the next one. Now the whole team, including the product owner and other customers as needed, meet for an hour or less the day before the planning meeting for our next sprint.

We laughingly call this the “pre-planning” meeting. We go over the stories for the next iteration. The product owner explains the purpose of each story. He goes over the business conditions of satisfaction and other items in his story checklists, and gives examples of desired behavior. We brainstorm about potential risks and dependencies, and identify steel threads where appropriate.

Sometimes it’s enough to spend a few minutes listening to the product owner’s explanation of the stories. At other times, we take time to diagram thin slices of a story on the whiteboard. Figure 16-1 shows an example diagram where we got into both the details of the UI flow and the database tables. Note the numbers for the “threads.” Thread #1 is our critical path. Thread #2 is the second layer, and so on. We upload photos of these diagrams to the wiki so our remote developer can see them too.

Figure 16-1 Sample planning whiteboard diagram

We can start thinking about what task cards we might write the next day and what approach we might take to each story. For some reason, being able to ruminate about the stories overnight makes us more productive in the actual iteration planning meeting the next day. After doing this for a few iterations, we were spending less time overall in planning the iteration, even though we had two meetings to do it.

Sometimes we pull in other customers to discuss stories that affect them directly. If they aren’t available right then, we still have time before our iteration planning meeting to talk to them to clarify the story.

In one pre-planning meeting, our product owner introduced a story about obtaining performance data for mutual funds. We would send a file to the vendor containing a list of mutual funds, and the vendor would provide an XML file on a website with all the latest performance information for those funds. We would then upload that data into our database.

In the pre-planning meeting, we asked questions such as, “What’s the format of the file we send the vendor?” “Is the ‘as-of’ date for each fund always the last day of the month?” “Is there any security on the website that contains the XML?” “Will we ever get a record for the same fund and “as-of” date that has new data, or can we ignore records with a date we already have in our database?”

By the next day’s iteration planning meeting, the product owner had obtained answers to all our questions. Writing task cards went quickly, and coding could proceed with correct assumptions.

Often, we find a much simpler solution to a story when we discuss it in the pre-iteration planning discussion. We found that to go fast, we needed to slow down first.

—Lisa

Do You Really Need This?

Your team may not need much or any advance preparation. Pierre Veragen and Erika Boyer described to Lisa how their teams at iLevel by Weyerhaeuser write user acceptance tests together at their iteration kickoff meeting.

These tests, which were written on a wiki page or some similar tool along with the story narrative, are used later when team members write task cards for each story and start writing more tests and code. Examples are turned into executable tests. Because the tests change as the team learns more about the story, the team may opt not to maintain the original ones that were written at the start. Keep it simple to start with, and dig into details later.

Lisa subsequently observed one of their planning sessions and saw first-hand how effective this technique was. Even when the product manager provides concrete examples, turning them into tests may flush out missing requirements. Their team did not need to do this before the iteration planning session, but it is not the case with all teams.

Lisa’s Story

My team liked the practice of writing tests together, but because we were writing task cards during iteration planning, we decided to write user acceptance tests together during the pre-planning meeting. We found this kept our discussions focused and we understood each story more quickly. We also did a better job of delivering exactly what the customer had in mind. Our customers noticed a difference in quality, and our product owner encouraged us to continue this practice.

—Lisa

Experiment with short pre-iteration discussions and test-writing sessions. It’ll take you several iterations to find your team’s rhythm, and find out if advance story discussions make you more productive during the iteration.

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.