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:
- Explore Quality Requirements
- Choose Testing Strategies
- Explore Stakeholder Needs
- Explore Quality 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
Practices
- Acceptance test-driven development
- Capturing functional requirements
- Controlling work-in-process (WIP)
- Daily coordination
- Decomposing a feature into stories
- Estimation
- Iteration demonstration and review
- Iteration demonstration and review (plan)
- Iteration planning meeting
- Iteration retrospective
- Operational metrics
- Unfinished work
- Visual controls