Acceptance Test Driven Development (ATDD)

ATDD (Acceptance Test Driven Development) is an interesting topic and has been around for some time, however, initially I had failed to understand it in totality. After some reading and some on the job experience, I am presenting my understanding on ATDD (Acceptance Test Driven Development) through this blog post. At the end of this seemingly technical text, if you exclaim that this is just some common sense that could be potentially useful in your agile project; I would consider my writing has made a reach!

Formally,

“Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. It’s the best way to ensure that we all have the same shared understanding of what it is we’re actually building. It’s also the best way to ensure we have a shared definition of done.”

(Source for definition: 

http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview/)

You should try ATDD if:

• You keep getting different viewpoints and concerns from stakeholders, product owners, developers and tester on the same story.
• You have a large agile team spread across various work locations.
• You have encountered situations wherein misunderstandings occur often because no one knows the misunderstandings exist and no one asks about them right up.
• Discussions on requirements often happen after defects are found-whether or not a defect is a defect or a future story!
• Developers and testers often get a different understanding of the same story.
• You want the testers to contribute through quality assurance, quality control, revealing holes in stories, other misalignment and eventually reducing risk.

ATDD process:

• Discussions take place over confirmation criteria of the story by the whole team. Inputs for test scenarios are obtained from all team members including stakeholders, product owners, developers and testers. All requirements clarification happen upfront. This happens just before, on or just after the day of planning for the iteration.
• Consensus obtained from all regarding the acceptance tests at the earliest.
• Testers begin to drill down the acceptance tests into test cases. Developers begin coding with the acceptance tests in hand.
• Coding is done. Testers test using their test cases to see whether acceptance criteria has been met or not. If a defect is found that hinders meeting of the acceptance criteria, the developer fixes the defect and retesting is done.
• Testers also perform exploratory testing ( by using domain knowledge, creativity and minimal planning)
• The team demos the working software for the story to the Product Owner for acceptance. Also, results of the exploratory tests, other potential risks, misalignment are highlighted. This often feeds as the input for future stories.

Some of these points might clarify your doubts at this stage:

• The questions that are asked to derive the acceptance tests from the confirmation criteria probably are as- How will we know we have done that? What about these? Does this also mean this? What would happen if otherwise?
• Acceptance Test Driven Development (ATDD) is NOT a testing technique. It is a development process wherein acceptance tests are specified upfront before any coding takes place.
• Acceptance Test Driven Development is actually NOT about testing. It is about communication, collaboration and clarity to counter notorious requirements that could be misunderstood and the unknown unknowns.
• Breaking down acceptance tests into test cases ( top-down approach) ensures completeness and alignment to what the customer expects.

Benefits of Acceptance Test Driven Development:

• Requirements clarification is done upfront. Whole team is on the same page.
• Inputs from all. Consensus from all. Works good for non-collocated teams.
• Developers code to meet acceptance criteria.
• Less chance of getting a defect that prevents acceptance of story.
• Testers' work gets cross-checked.
• Prevents unnecessary code changes/discussions towards iteration end.
• Smooth acceptance. Gives testers enough time for regression, highlighting risks and mis-alignments.
• More avenues for defect prevention

ATDD Vs TDD, BDD and Industry Trends:

• If you are browsing through this topic, you should also browse about BDD (Behavior Driven Development ) , TDD (Test Driven Development) and Specification By Example
• If you are interested in knowing about related tools and frameworks, do have a look at Fitnesse, Cucumber, Spectacular, Concordion, Thucydides etc.