Goals of Up-Front Tester Activities

Based on our experiences, we think the role of the tester during story writing and release planning is characterized by four goals:

1. Identifying and making explicit hidden assumptions in the stories. Remember Lisa's missing door from Chapter 2? That's what we're talking about here. As a tester, your goal should be to avoid the "missing door" syndrome by identifying the assumptions that the customer has hidden in the stories.

2. Defining some acceptance tests for each story. We recommend writing acceptance tests for the stories as soon as possible, before iteration planning. This turns out to be an excellent way maybe the best way to get the customer's hidden assumptions out into the open. These will just be high-level acceptance tests for now you don't want to spend too much time fleshing out stories the customer may never choose. By including acceptance tests along with the narrative of the story, the team can make much more accurate estimates of each story's cost during release and iteration planning.

3. Including time for acceptance tests in story estimates. It's your responsibility to get the time required for acceptance testing into the planning game in some form. You can add your estimates to those of the programmers or create additional stories that represent acceptance testing activities and put the estimates there.

4. Enabling accurate estimates of time and velocity. You can help programmers with their estimates on the user stories. While remembering that you're part of the development team and not an adversary, you can still afford to be a bit more pessimistic than the programmers (e.g., more like Nostradamus than Pollyanna). You can make sure estimates include enough time for automating and debugging tests, running tests, fixing bugs, and retesting.

We've found that accomplishing these goals during story writing and release planning has a big payoff later in the project. Is the tester the only one working on these things? Absolutely not: XP calls for programmers and the customer to do these things. But in practice, these goals can be overlooked in the rush to produce. A tester who's focused on them helps the rest of the team meet them.

Flushing out the hidden assumptions in the stories helps programmers implement more accurately the first time around, which makes for happy customers. XP may be self-correcting in terms of bringing these things out in the open eventually, but clearing them up earlier allows for more velocity later on.

Specifying acceptance tests up front with the stories is really a type of test-first development. It helps avoid some types of defects altogether and gives the team a head start on test automation and test data acquisition. This allows functional testing to keep up with the programmers at crunch time, when the end of the iteration approaches.

Including acceptance test tasks in the stories and enabling accurate story estimates makes release and iteration planning more accurate and provides time to automate the tests, which pays off many times over in later iterations.

In the next chapters, we'll expand on each of these goals, discuss effective ways to accomplish them, and provide examples.