Defining Acceptance Tests


Purpose

Acceptance tests are an important part of Extreme Programming, but all too often they are ignored. This exercise enables participants to become familiar with acceptance tests.

Description

As part of the preparation for the tutorial, the instructors got together and brainstormed ideas for applications. The criteria for the application were that it had to be interesting, nontrivial, and understood by both Europeans and Americans (because XP2001 has a large concentration of European attendees). The application that we selected was an electronic teller.

Then we wrote the user stories that described this application. We wrote about 40 user stories in just under an hour. The goal was to get a fairly large volume of stories. However, the goal was not to write especially high quality stories. We purposely wrote stories that were duplicates of other stories, included contradictory requirements, were too vague, and were much too large.

We gave each group of participants a copy of these stories and gave them 45 minutes to define the corresponding acceptance tests. The participants were told to write the acceptance tests on the back of the story cards.

Events

In this exercise all the participants played the role of the customer. Again, many of the groups had a hard time getting started. Some of the groups read all the stories before writing acceptance tests. Some of the groups split into two smaller groups, with each of the smaller groups taking about half of the story cards. A few groups just started writing tests.

The instructors gave warnings every 15 minutes, but other than that, all they did was observe and answer questions. Very few groups asked any questions about the stories, even though we were standing close enough to hear them talk about what they didn't understand.

At the end of the time limit, none of the groups had acceptance tests for all the stories, but all the groups had some acceptance tests. The groups shared their acceptance tests with all the participants.

Many of the groups had similar tests. The acceptance tests that were written tended to use the same approach.

The groups also tended to write tests for the same stories. This was true even though the story cards were shuffled and were not given to the groups in the same order. One story that all the groups wrote a test for was "Allow customer to make a deposit." A sample acceptance test for this story follows.

 Acceptance test     Establish account     Make deposit     Verify balance is correct 

Several teams had variations of this same basic test. It was interesting to note that the acceptance tests tended to be vague. Even though the developers knew that they prefer to get acceptance tests that are more explicit, when the groups were writing the tests, they kept making the tests too fuzzy. An example of a more specific version of the same acceptance test follows.

 Acceptance test     Establish account         Account number = 1231234556         Account owner = John Smith         Starting balance = 921.53     Make deposit         Deposit amount = 51.21     Verify balance is correct         Updated balance = 972.74 

The groups also tended to have difficulty writing acceptance tests for the same stories. One story that none of the teams managed to write an acceptance test for was "Transform electronic teller into an armored car and have it drive to bank to make pickups." The stories that the groups were unable to write acceptance tests for were the stories that we considered lower-quality stories.

Summary

The participants already knew how to define acceptance tests; they just needed practice and reminders about what makes a good acceptance test. The stories that the groups had problems with were either too large or too vague.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net