Disciplined Agile

Practice: Acceptance Test-Driven Development

Why to Do This Practice

Acceptance test-driven development (ATDD) defines acceptance tests for requirements prior to implementing those requirements. The acceptance tests represent the specific details of the capability that will be delivered. Defining these tests up-front gives a high confidence that the system will meet the expectations of the customer.

ATDD has been shown to have numerous benefits, including:

  • Little room for miscommunication
  • Workflows working the first time
  • Getting business rules right
  • Tighter cross-functional team integration
  • Crisp visible story completion criteria

Who Does This Practice

There are three groups (the triad) involved in the practice:

  • Customer. The customer group, who are requirements requestors. This group can include:
    • Customer
    • Business sponsor
    • Technology sponsor
    • Stakeholders
    • PM/BPO
    • Business project manager 
    • Product owner 
  • Developer. The developer group, who are requirements implementers.
  • Tester. The tester group, who monitor implementations of requirements.

What to Do 

An approach where tests help specify the product/service. Automation is desirable for regression testing, but not required to implement the tests.


Inputs to this practice include: 

  • Co-working relationship with the customer(s)
  • Means of specifying acceptance tests that are easily read and understood by the customer as well as the developer 


There are several approaches for performing ATDD.

  • Collaborate on ubiquitous language
  • Develop examples, demos, prototypes, etc. to understand requirement
  • Lead with “what would you want to see “
  • Create scenarios (typically in the “Given-When-Then” format)

Process Goals

Disciplined Agile® Delivery (DAD) describes process goals to help with capturing functional requirements:

Tools and Techniques

Tools for managing TDD include:

  • Gherkin (test syntax), Cucumber (Java and other languages), Specflow (C#)
  • FIT (Framework for Integrated Test)
  • FitNesse (using a wiki for using FIT)


Output from this practice include:

  • Acceptance tests that are always as mature as the requirements
  • Optional (but usually highly desirable): automated tests for scenarios.

When to Do This Practice

ATDD starts when requirements are first being developed.


Fewer defects due to misunderstood requirements.