Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing


Click here to view the complete list of archived articles

This article was originally published in the Summer 2008 issue of Methods & Tools

Acceptance TDD Explained - Part 3

Lasse Koskela

2. Acceptance tests

Acceptance tests are specifications for the desired behavior and functionality of a system. They tell us, for a given user story, how the system handles certain conditions and inputs and with what kinds of outcomes. There are a number of properties that an acceptance test should exhibit; but before taking a closer look, let’s see an example.

2.1 Example tests for a story

Let’s consider the following example of a user story and see what our acceptance tests for that particular story might look like. I present you figure with 1.

Figure 1. Example of a user story, written on a story card

The functionality that we’re interested in is for the system to obtain and display the customer’s history of records when a call comes through the customer support system. I might, for example, think of the tests for this story that are scribbled down as figure 2.

These three tests would essentially tell us whether the system behaves correctly from the perspective of a user—conditions of satisfaction. They tell us nothing about how the system implements that behavior.

Now, with these example tests in mind, let’s look at some essential properties of acceptance tests, starting with who owns them and who writes them.

Figure 2. Example tests for the story, written on the back of the story card from figure 1

2.2 Properties of acceptance tests

So far, you’ve probably deduced that acceptance tests are typically short and somewhat informal. There’s more to the nature of acceptance tests, however, and next we’re going to look at some general properties.

To make a long story short, acceptance tests are

  • Owned by the customer
  • Written together with the customer, developer, and tester
  • About the what and not the how
  • Expressed in the language of the problem domain
  • Concise, precise, and unambiguous

Let’s expand these sound bites one by one and see what they mean.

Go to part 2    Go to part 4    Back to the archive list

SpiraTeam Agile ALM

Software Testing Magazine

Scrum Expert