Chapter 6: The First Customer Acceptance Test

Sometimes, too often, XP teams don t have Customer Acceptance Tests or they leave them until later. The result is a less confident customer and problems when you least need them. Here s our first customer test. See? That wasn t hard.

Do We Need a Customer Test?

In the previous chapter, I mentioned, in a screaming sort of tone of voice, that we need a customer test. Extreme Programming teams use at least two levels of testing: programmer tests, like we ve already been writing, and customer tests. The main distinguishing characteristic of a customer test is that it belongs to the customer. That ownership is important.

The basic cycle of the project is that the customer says what she wants and the programmers build it. For the cycle to work, the programmers have to become clear on what the customer wants, so that they can build it, and the customer needs to be sure whether the programmers have built what she asked for. Thus, the customer test is born. We say sometimes that an XP story has three aspects:

• Card A sentence or two, written on a ^sb card, used as a token in planning what is to be done. Teams typically write estimates on cards and often carry them around or post them on the walls when the stories they represent are being worked on.

• Conversation A series of discussions between the programmers and the customer, building understanding of what the story really means. This conversation is often supported with paper or electronic documentation, but the character of conversation ”two-way communication ”is always present.

• Confirmation One or more concrete, executable, automated Customer Acceptance Tests. These tests are written in an unambiguous language, either a conventional programming language, or a scripting language, or a little table language. Preferably, the language is one that the customer can understand, ideally one that the customer can produce herself.

The rule is: ^sb The story s not done till the customer tests run. Unfortunately, it s common for teams to leave acceptance tests until later or sometimes to skip them altogether, often for reasons the team considers good ones. Maybe they think that testing should be done by the QA people, or maybe they think that the system is GUI-based and that automated tests are not necessary. Maybe they are waiting for a testing framework that has not yet been created or not yet arrived in the mail.

None of these reasons are good enough, in my opinion. Customer tests are a critical aspect of the process. The tests amount to an unambiguous written requirements document! And they constitute the best possible kind of requirements document, because they can be verified by the computer. So don t go skipping your acceptance tests. Don t make me come over there!

Still, it might be difficult to do the customer tests, and it takes a little discipline. In this book, we re not going to ship the first story until we have automated Customer Acceptance Tests, and we ll show you how we got ours. With luck, they ll help you get yours.