You can do acceptance test-driven development (ATDD) manually without the aid of a tool by just keeping track of the acceptance criteria for a story and noting when it meets the criteria. Automating the process is helpful but the real value comes in articulating the acceptance criteria ahead of time.
It is estimated that more than half of the defects and half of the cost in software development is due to poorly articulated requirements. Written requirements for software is ineffective because spoken language isn’t precise enough to articulate effectively the behavior of software. However, we found that by articulating examples of the behavior that we want to create we can more accurately and easily describe the behavior in a way that allows us to implement it naturally. Development becomes a process of working through an example, which has many advantages over trying to code in the abstract.
One of the first acceptance test-driven development frameworks were called FIT, which stood for the Framework for Integrated Testing. It was basically an interpreter that allows you to specify acceptance tests by entering information in HTML tables, which were then parsed and used to generate automated acceptance tests.
The premise was that if acceptance tests were expressed in HTML tables then customers would be more apt to maintain these tables. In my experience that doesn’t always happen but in the rare cases that it does happen then it can be great. Often I find that the responsibility for maintaining acceptance tests goes to the software development team but often the value of these tests is so great that the team has no problem maintaining them.
The main burden and effort in ATDD are in the process of creating acceptance tests in the first place. This is done in partnership with the Product Owner and it allows the team and the Product Owner to gain immediate consensus on what features should do and therefore when the developers can move on to work on the next feature.
Today we have a range of tools to help us write good acceptance tests. Tools like SpecFlow for .net and Cucumber for Java are examples of acceptance test-driven frameworks that use the Gherkin language to allow us to express acceptance tests in a human-readable form that can be easily translated into something that the computer can run against and validate.
Notice that acceptance tests aren’t tests in the traditional sense. Rather, they are assertions of behaviors for features in the system. This helps us define the feature but it is often defined at too high a level to help us actually build out the feature. For that, we use test-first development. Acceptance test-driven development is at the right level to help us define the feature from the Product Owner’s perspective so that we build it to have the intended value.
Right next to continuous integration I find that automating acceptance criteria through acceptance test-driven development to be one of the highest value activities teams can engage in. It’s especially valuable for helping the relationship between developers and the Product Owner so the teams build more of what the Product Owner wants and the Product Owner is able to more accurately articulate what’s needed.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Know Who it’s for and Why They Want it
Next Post: Specify Edge Cases »