Chapter 5. Overview of the XP Tester Role

Now that we've provided some reasons why we think XP projects need a tester, we'll describe what that job involves. When we talk about the tester role on an XP team, we don't mean one person is responsible for all testing, or even all acceptance testing. Keep in mind that XP strives to avoid specialization, so everyone on an XP team contributes to test development and execution. More than one person may often play the tester role, and the tester may also play multiple roles, using a wide variety of skills.

To quote Ron Jeffries, "XP is not about 'roles' at all. It is about a much tighter integration of skills and behaviors than is implied by the notion of roles" (e-mail). Acceptance testing in particular does not get done properly in XP unless the whole team embraces it as an essential collective responsibility.

Paraphrasing Ron again, the idea behind the XP testing practice is that testing is an integrated activity, not a separate one. Feedback should be continuous, with the customer expressing needs in terms of tests and programmers expressing design and code in terms of tests. In XP as it was envisioned, testing activities and skills are needed across the whole team, with no tester role into which we can plug a person and say we've accounted for testing.

While we acknowledge that the two official XP "roles" are customer and programmer and that testing is a team activity, our experience has shown us that on most XP teams, one or more persons need to wear the tester hat, focus on acceptance testing, and provide leadership in the areas of testing and quality assurance to the rest of the team. This is what we mean in this book when we talk about the tester role. We're not equating or comparing it with the customer and programmer roles. In fact, the tester will play both of these roles within the team. If you have a problem using the term role in this context, then think focus. We'll refer to a person in the tester role or with the tester focus as simply a tester from this point on.

The tester may pair to write production code or write test code alone. She'll certainly provide a quality assurance role in preventing defects from occurring in the future by learning from current failures. Testers raise the team's consciousness about quality and promote best practices in every stage of software development, from requirements gathering to launch.

Like everyone on the XP team, the tester has rights and responsibilities and many hats to wear. The tester's duties include two often conflicting roles: customer advocate making sure the customer gets what he asked and is paying for and programmer advocate making sure the customer doesn't take unfair advantage of the programmers to the detriment of the project. (This could also be the job of the programmers themselves or the coach, but it's an area where testers can contribute.)

As a tester, you think about the system as if you were the customer. Not about how you're going to build it but how you're going to "live" in the end result. Use this viewpoint to figure the most important things to verify, then use your systems knowledge to come up with all the details the customer may not have thought of.

Yes, in XP the customer is responsible for specifying the level of quality needed via the stories and acceptance tests. But a customer may think he knows what he wants, just as Lisa thought she knew everything she wanted in her house addition. She did read scores of British home design magazines, but that doesn't mean she knew anything about construction.

Besides overlooking details they should care about but are unaware of, customers as a group are not terribly experienced in quality assurance and testing. If stories aren't well defined and acceptance tests are not thorough, you may get through plenty of iterations with everyone happy, and then BAM! A customer might not notice a missing door until an end user complains about it.

We've already talked about the value of courage as it applies to XP testing. Testers, too, have a lot of fear about XP. Much of this is due to misperceptions about XP.

Testers are afraid that

• There isn't enough process.

• They won't have enough detail to understand the stories.

• They won't be able to get the tests written fast enough to execute them in the same iteration.

• They won't be able to automate tests fast enough to keep up with the rapid iterations or they won't know how to automate the tests, period.

• They'll have to sacrifice quality for deadlines.

• They'll get stuck between a demanding customer and frustrated programmers who argue over whether a function or performance criterion was really part of a particular story.

• The documentation won't be sufficient.

• Nobody will help them.

• They won't be able to pick up new technology fast enough.

• They won't have time to do thorough enough testing.

• The software won't meet their personal quality standards.