Chapter 15. Nailing Down the Details

Drilling down for acceptance-test details really requires getting out all the hats in your wardrobe. You need to be able to look at the system through the eyes of the customer to come up with a lot of the detail yourself, so you don't overwhelm the customer with questions. Likewise, you'll need to reason about the system from a programmer's viewpoint, to predict some of what the system is likely to do without overwhelming the programmers with questions. Finally, you need to put on the tester's hat and determine the set of tests that can be realized in the time available and that will best distinguish an acceptable system from an unacceptable system.

When you're defining all the details of the acceptance tests with the customer, you might find he needs a more robust system than was discussed during the Planning Game. This is an indication that he needs to write new stories for the remaining iterations to get what he wants. As we discussed in the previous chapter, higher external quality often means more time and/or more cost.

Remember, XP is a team effort. Programmers also provide input into the acceptance tests. They know what areas of the system have the most technical risk. They can propose alternative solutions to a problem, so the customer can decide on the best approach. When you ask questions of them or confirm what system behavior will be, a disconnect may become obvious between what the customer said and what the programmer heard.

The more quickly you can write the acceptance tests, the better. Not only does this help the programmers know exactly what they're programming, it also gives everyone time to build the necessary bridges into the system code. We'll talk about this more in the next chapter.

As we've pointed out before, XP calls for the customer to define the acceptance tests. If your customer is capable of writing tests and is willing to do this on her own on the first day of the iteration, great. If she's available the first day of the iteration to sit down with you to write the tests together, that's ideal. If you need to get the tests written and the customer can't start right away, start writing the tests yourself and arrange to meet with her by day 2 of the iteration at the latest. The guidelines in this chapter will help everyone who has to write acceptance tests. Since our experience is that we always end up writing the first cut of the tests, we've written the chapter this way.