Catalog
method#Quality Assurance#Delivery#Integration#Product#Reliability

Acceptance Test-Driven Development (ATDD)

A collaborative practice where stakeholders, testers and developers define acceptance criteria as automated tests before implementation.

Acceptance Test-Driven Development (ATDD) is a collaborative practice where stakeholders, testers and developers define acceptance-focused tests before implementation.
Established
Medium

Classification

  • Medium
  • Organizational
  • Organizational
  • Intermediate

Technical context

CI/CD systems (e.g. Jenkins, GitHub Actions)Test frameworks (e.g. Cucumber, SpecFlow)Test data and mock services

Principles & goals

Shared language: acceptance criteria act as a single source of truth.Test early: tests are specified before implementation.Automation: acceptance tests are repeatable and integrated into CI.
Build
Team, Domain

Use cases & scenarios

Compromises

  • Tests become too detailed and bind implementation details.
  • Incorrect or incomplete acceptance criteria lead to wrong implementation.
  • Overreliance on tools can limit flexibility.
  • Focus on behavior rather than implementation details in scenarios.
  • Keep tests short and isolated to avoid flakiness.
  • Integrate tests early into CI and measure feedback times.

I/O & resources

  • User stories and acceptance criteria
  • Domain stakeholders for clarification
  • Test automation framework and CI pipeline
  • Automated acceptance tests as specification
  • Reduced number of unplanned reworks
  • Better documented requirements

Description

Acceptance Test-Driven Development (ATDD) is a collaborative practice where stakeholders, testers and developers define acceptance-focused tests before implementation. The goal is early clarification of requirements, automated acceptance tests and fast feedback. ATDD significantly reduces misunderstandings and improves test coverage in the development process.

✔

  • Clear requirements and less rework due to misunderstandings.
  • Fast feedback and more stable releases through automated tests.
  • Improved collaboration between business, QA and development.

✖

  • Effort to maintain and update acceptance scenarios.
  • Requires disciplined collaboration and relatively stable requirements.
  • Not all non-functional requirements can be expressed as acceptance tests.

  • Percentage of automated acceptance tests

    Share of acceptance criteria covered by automated tests.

  • Mean Time to Feedback

    Average time from defining a scenario to receiving CI feedback.

  • Regression detection rate

    Share of regression bugs detected early by acceptance tests.

E‑commerce checkout

Acceptance criteria for the payment flow were defined as automated tests and run in CI, surfacing payment errors early.

Online banking transfer

Regulatory requirements were captured in ATDD scenarios and documented as an audit trail.

API versioning

Compatibility requirements between API versions were enforced via acceptance tests.

1

Step 1: Train the team in ATDD principles and Given-When-Then format.

2

Step 2: Run feature workshops with stakeholders to define acceptance scenarios.

3

Step 3: Implement minimal functionality until tests pass.

4

Step 4: Automate scenarios in the chosen test framework and integrate into CI.

5

Step 5: Regular maintenance and review of tests upon changes.

⚠️ Technical debt & bottlenecks

  • Obsolete acceptance scenarios that no longer match current business rules.
  • Monolithic test suites with poor execution performance.
  • Lack of test data management for reproducible tests.
Unclear requirementsInsufficient test toolingCoordination overhead between teams
  • Acceptance tests are created as lengthy UI scripts and are fragile.
  • Business stakeholders are not involved; tests reflect wrong assumptions.
  • Tests are not maintained and lead to many false positives.
  • Fixing details too early forces implementation concepts.
  • Insufficient test data leads to unstable tests.
  • No clear separation between acceptance and unit tests.
Ability to formulate acceptance-focused scenariosExperience with test automation and CICommunication and facilitation skills for workshops
Traceability of business requirementsDegree of automation in CI/CDInterface and integration stability
  • • Availability of domain stakeholders for sessions
  • • Limited resources for test automation
  • • Legacy systems without testable interfaces