Set the Quality Criteria

As the XP tester, ask lots of probing questions during the planning game. If the customer says, "I want a security model so that members of different groups have access to different feature sets," ask, "Do you want error handling? Can the same user be logged in multiple times? How many concurrent logins should the system support?" This may lead to multiple stories, which will make estimation much easier.

Our customers have rarely thought of things like throughput capacity and stability up front instead, they assume that their intentions are obvious: "Well, of course I want to have more than one user log in at a time." The tester should turn assumptions into questions and answers. This way, you don't end up with doorless rooms.

Write acceptance tests that prove not only the intended functionality, but also the desired level of quality. Discuss issues such as these with the customer.

• What happens if the end user tries a totally bizarre path through the system?

• What are ways someone might try to hack past the security?

• What are the load and performance criteria?

As a result of these discussions, you may need to get the team back together to see whether stories need to be split up or new stories written, and reestimate stories to reflect the quality standards the customer has set in the acceptance tests. The customer will have to drop a story or change the mix, but they will be happier with the end result. Higher external quality means more time and more cost! Both a VW Beetle and a Hummer will get you to the grocery store, but if you need to cross the Kuwaiti desert, you're going to have to pay for the vehicle that's designed for the job.

Participate in developers' task assignment and estimation sessions. Testers often have more experience in dealing with customers and a better understanding of what the customer meant to request. If the story is for a screen to add a record to the database, it's likely that the customer also meant they wanted to be able to read, update, and delete records. Get everyone back together if there have been assumptions or a disconnect in understanding. Testers are in a unique position to facilitate this process.

I work in the same room as the developers, pair with them when needed, and participate in the stand-up meetings. At the same time, I try to have as much contact with the customer as possible: We discuss the tests, get together to run them, and look at the results. Testers are part of the development team much more so than in a traditional software process. But as a tester, you need a level of detachment; you have to be able to be an advocate for the customer and at the same time a guardian of the developers. This can be a lonely and difficult role at times. The beauty of XP is that you're never alone. With the help of your team, you can enhance the customer's satisfaction.