The Tester s Role in Iteration Planning

The Tester's Role in Iteration Planning

In a lot of ways, iteration planning is like release planning on a more detailed scale. You'll be looking at some of the same stories but will see more of the specifics involved in each, because you're taking a closer look. Since the story estimates include time for acceptance testing (thanks to you), the velocity will, in theory, include the resources for acceptance testing. Keep the Tester's Bill of Rights in mind during this process. You may realize, as you see more of the details, that the initial estimate was too low.

Thinking of All the Tasks

Your priority during iteration planning is to help the team think of all the tasks they'll have to do to finish a story. Finishing a story means not only coding and integrating it into the system but also developing and executing the acceptance tests that demonstrate that the story is present, correct, and complete. You'll tend to think of tasks along those lines, whereas the programmers will likely focus on the coding, integration, and unit testing.

You can help get several categories of often overlooked tasks into the iteration plan. Some of these are one-time tasks that can be taken care of in the first iteration or so; others might extend over multiple iterations.

• Development infrastructure. These tasks usually come up when you have a brand-new team and project. Your team needs to decide what source-code control tool to use, what to use for building packages, what integrated development environment (IDE) to use, how to track defects, whether to use a particular development framework anything related to coding and building the system. The programmers will probably be making the decisions and so are likely to think of some of these tasks, like evaluating and purchasing, but often overlook those involved with training, learning, and tweaking, especially with new technology.

• Release packaging. At the other end of the process, these tasks relate to how the system is delivered to the customer at the end of each iteration and release. This may be trivial, like zipping the code up into an archive and handing it to the customer on a CD, or it could involve any amount of specialized formats and delivery mechanisms. Since one of the strengths of XP is that the customer can decide at the end of any iteration to walk away with the functional system he has at that point, consider release packaging even during the first iteration.

• Production environment. These are tasks that may be required by the customer to integrate the delivered system into an existing production environment. For a brand-new, stand-alone system, these would be trivial. For an extension to a currently functioning system or a new system that integrates with an existing production environment, extensive regression and performance testing could be required, to validate that the newly delivered iteration will not cause problems.

• Test infrastructure. These tasks are associated with creating and maintaining a functional test system and obtaining and using test tools.

• Acceptance testing. These tasks are associated with defining tests, creating test data, developing test automation, and with executing, evaluating, and reporting tests.

These last two, test infrastructure and acceptance testing, are the areas where the tester has primary responsibility for defining and estimating tasks. We'll talk about these in detail a bit further on.

Enhancing Communication

In addition to actively identifying tasks, you have a role in facilitating communication and understanding between the customer and development teams. You also strive for the best possible estimation of all tasks, as you did in release planning.

During iteration planning, you often need additional explanation of some or all of the stories the customer team selected. Sometimes they'll find they didn't completely understand a story, and now that they have all the facts, they need to reestimate it. It's much better to do this now than to come up short at the end of the iteration. Remember that getting even 90% of each story done still equals zero percent completed stories and a velocity of zero for the next iteration!

Be alert for assumptions by development and customer teams. If you remember that the customer wanted a confirmation screen for sending a message and the programmers don't have a task to create it, bring up the issue. If the programmers misunderstood something that has a major impact on a story estimate, the story has to be reestimated. If the estimate is large enough to exceed the velocity for the iteration, the customer has to choose a story to leave out. Remember that although it's hard to have to ask the customer to ditch a story for now, it's much better than coming to the end of the iteration with stories not 100% complete! The deadline in XP is never negotiable. You have to collaborate with the customer on scope and make adjustments whenever needed.

The development team, including testers, may find estimating tasks to be hard at first. Estimating is tricky in the first iteration; you have no history for this particular project on which to base your estimates. Your team may estimate in time-independent points, pair hours, ideal programming hours, or some other system. Take your best shot experience will improve your estimating ability. Your priority during iteration planning is to help the team think of all the tasks they'll have to do to finish a story.

The person estimating the task may be the one ultimately responsible for completing the task. However, some teams simply put all the tasks back into a bucket, and the person picking up the task later may not be the same one who estimated it. The person responsible for the task can reestimate it later if necessary.