Acceptance Test-Driven Development (ATDD)

Acceptance Test-Driven Development (ATDD) is a software development method that brings technical and non-technical people together to create a high-value product in collaboration with the customer. It is related to Test-Driven Development (TDD) but while TDD is code-centric and focuses on the inside of the software (how the code solves the problem) ATDD can be described as outside-in with the focus on the software’s behavior. It is about what the software does to solve a problem.

ATDD was first mentioned in 1957 by D. D. McCracken who wrote in his book Digital Computer Programming about how the customer should prepare acceptance check cases before programming begins.

ATDD is also closely related to BDD and Specification by Example and many popular tools like Cucumber, SpecFlow, Behave and others can be used to improve customer - programmer/tester collaboration.

ATDD works best in combination with modern product management and discovery techniques and, in general, when an agile and lean mindset is present.

This page is supposed to provide an overview and provide pointers to more material about ATDD.

• References to ATDD
• My own articles
• ATDD overview by Elisabeth Hendrickson

How to learn ATDD

Anyone can learn ATDD on their own.

A faster way, that avoids timely and costly detours, is to retain a professional software development coach. A professional coach has seen many different implementations of the ATDD concept and is able to figure out how to best change an existing workflow towards one that supports ATDD without too many interruptions of ongoing work.

A professional coach can also sense when some people are unwilling to change how they work and help to fix that over time by working with those people. Sometimes additional help is required and it is likely that the coach has people in his/her network with the right skills to contribute temporarily.

ATDD is not a software development methodology

ATDD is just a technique or a method that can be used in a number of ways. There is no prescriptive process to follow. I believe that every team, every company should find their very own way of taking advance of ATDD. After all it is about collaboration between everybody working on a software solution to a given problem. Who everybody is will be different in every case and therefore how these people work together also will be different. As long as there is collaboration and not just mere cooperation some useful practice of ATDD will emerge - for that particular group.