Both Acceptance Test-Driven Development (ATDD) and Behavior-Driven Development (BDD) are primarily about increasing collaboration and achieving and understanding of what needs to be built. Both are about communication, collaboration and clarity. Requirements are notorious for being misunderstood. Agile methods attempt to overcome this by working on small stories and building things in small steps. While this helps, it is better to avoid misunderstandings than it is to catch them quickly. The challenge with requirements is that customers, stakeholders, product owners, developers and testers all have different backgrounds and different concerns.
The standard way of “getting requirements” is for the product owner to discuss what’s needed and to have the development team ask questions to get clarity. Developers will ask for clarity about what they are not sure of and of what they don’t know. We often think that there’s what we know and what we don’t know. But there’s actually a larger class of information – what we don’t know and we don’t know we don’t know it. While that may sound a little funny, it is just this information that makes requirements so confusing. Product owners discuss the requirements with developers, misunderstandings occur, but no one asks about some of these because no one knows the misunderstandings exist. Questions will be asked, but only about those things the developers know they don’t know. It is this “unknown unknown” that causes all of the problems.
The question is how do we get to this area of misunderstanding? What is needed is a way of evoking questions when there is an unknown misunderstanding. ATDD is such a way. ATDD is conceptually very simple: product owners, developers and testers discuss the requirements by first asking what is needed, but then by asking the question – “how will we know we’ve done that?” This conversation creates specific answers to how to answer this question. These answers are in the form of acceptance tests. But it is actually the conversation and collaboration that creates these acceptance tests where the true value is. It is important to note that all of the work of getting these acceptance tests takes place even when one does not do ATDD. ATDD’s big shift is in having the acceptance tests specified up-front, before any code takes place. By getting all of the people involved before writing code misunderstandings are avoided while requiring little extra work.
Any ideas about the capabilities of an organization might develop to meet a customer need, are just speculative until the organization knows what it will truly take to satisfy the customer. These conditions of satisfaction are called “Acceptance Tests.” Development that includes defining these from the beginning is called “Acceptance Test-Driven Development” (ATDD).
ATDD requires working much more closely with the customer. The acceptance tests are co-developed with the customer. The tests represent specific details of the capabilities that will be delivered. Confidence is much higher that the customer will accept the developed product with far fewer changes, and less-significant ones, than under non-ATDD development.