PMI Sites
Register
Disciplined Agile
Search

    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

    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 

    Approach

    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)

    Outputs

    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.

    Outcomes

    Fewer defects due to misunderstood requirements. 

    Product Owner Overview