« Domain Driven Design | Home | Source Code for .Net Framework Libraries to be released later this year »

Acceptance Tests

By indomitablehef | October 5, 2007

This post is all “out of order”, since I should probably talk about User Stories first, but I feel guilty for not posting often enough, and when I have something to post, I reckon I’d better just throw it out there…so here goes.

Read up on User stories here: http://en.wikipedia.org/wiki/User_story

For every User Story, we should have one or more acceptance tests. I use index cards, (4×6, but I wish I had stuck with 3×5). I write the user story, title, number, and effort estimate (in story points) on the front of the card. I write the acceptance tests on the back of the cards. Like everything else along the way towards agile development, writing user stories and acceptance tests is a growing process. Our first pass at acceptance tests for our stories was woefully inadequate, but it got us used to the idea and got us thinking in the right direction - believing in the principle.

Now, we’re working on getting better at it -writing “good” acceptance tests. Remember that user stories are written by users. So are acceptance tests. Still, everyone will need coaching, and sometimes hand-holding. Take it slow, be a salesman, not a tyrant. (something I have to remind myself of)

Acceptance Tests
Think of them as a script that you will eventually use to evaluate whether a story is complete. Imagine a scenario where you write the story on the front of the card and hand it to the developer. When the developer is done, he returns the card to you. You then flip it over and proceed through the acceptance tests, and if all the conditions you specified are satisfied, then the story is done.

Acceptance tests are “black box”: that is, they focus on expected results or observable behavior. Avoid design discussions whenever possible.

An example:

Story: Add Patient Health Risk
The Clinician selects a drug from the patient’s list of drugs, and enters a Health Risk related to that drug. He selects Risk category/subcategory from drop-down lists (see cat/sub-cat list), and selects severity (severe, critical, major, moderate, minor) and status (identified, opened, closed-resolved, closed-unresolved, pending) , also from drop-down lists. He can enter notes for the HR and Sub-Category specific details (see list of detail fields for Health Risk sub-categories).

Acceptance Tests
1. A Clinician can view a patient, select a medication, and choose to add a Health Risk specific to that medication.
2. A Clinician can enter category/subcategory/status/severity/notes/sub-cat-details for the Health Risk and save it.
3. A Clinician can view a list of Health Risks for a patient and see, at a glance: Drug/Cat/SubCat/Severity/IdentifiedDate, Status. List should be able to “group by” the available columns and filter by status/severity combinations, as well as Identified date ranges.
4. The system automatically records status change dates and user info whenever the status of the Health Risk changes. Status history info is available on the Health Risk detail view.
5. The system will not allow the Clinician to add multiple Health Risks for the same drug with the same category/subcategory.

Things to notice:

Some questions to kick start the brain when writing acceptance tests:

Topics: Uncategorized |

Comments