Acceptance Test-Driven Development

Acceptance Test Driven Development (ATDD) is not about testing – it is 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.




Related Courses

Acceptance Test-Driven Development. A great course on Acceptance Test-Driven Development.

Please contact Mike Shalloway, Marketing & Sales Director to see about scheduling an ATDD course at your facilities.  Email or Call 888.532.6244


How To Start With Acceptance Test Driven Development.  There are many different ways to start with ATDD.  This blog covers them.

Lightning Webinars

Introducing Acceptance Test-Driven Development (ATDD). A quick introduction to Acceptance Test-Driven Development: How it helps communication between the business customers, developers, and testers. Covers the 5 W's: What are acceptance tests, who creates them, when they should be created, where they are used, and why You should use them.


Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. By Ken Pugh. Software development projects have been adopting agility at a rapid pace. Although agility provides quicker delivery of business value, lean principles suggest reducing waste, delays, and handoffs can provide even faster delivery. With acceptance test driven development, the business customer, the tester, and the developer collaborate to produce testable requirements.

These acceptance tests form the detailed specification of how the software should work from an external point of view. They help the customer to clarify their needs, the developer to have an objective to code towards, and the tester to plan for more than just functional testing.