Product Owner: Acceptance TDD

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

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

  • Customer. The customer group (requirements requestors).  This group can include:
  • Developer. The developer group (requirements implementers)
  • Tester. The tester group (monitors implementations of requirements)

What

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

  • 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)

Tools and techniques for Automation

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

Outputs

Acceptance tests that are always as mature as the requirements

Optional (but usually highly desirable): automated tests for scenarios.

When

ATDD starts when requirements are first being developed.

Outcomes

Fewer defects due to misunderstood requirements.