ATDD (Acceptance Test-Driven Development)

What it is

ATDD is a collaborative requirements practice where the whole team—business stakeholders, developers, and testers—work together to define acceptance criteria as concrete, testable examples before any code is written. These examples are then automated and become the living acceptance test suite.

The practice is often framed around The Three Amigos:

• Business (Product Owner / BA) — clarifies the problem, desired outcomes, and business rules.
• Development — identifies technical constraints, implementation approach, and edge cases.
• Testing — probes for ambiguity, missing scenarios, and risks from a quality perspective.

By the end of a Three Amigos session, the team has a shared set of acceptance criteria written as executable examples. These examples are automated (often using Gherkin syntax and tools like SpecFlow or Cucumber), run in CI, and operationalise the team's Definition of Done.

When to use it

Occasion	Why ATDD helps
Story refinement / backlog grooming	Clarify acceptance criteria before sizing; expose hidden complexity early.
Before development starts	Prevents rework caused by misunderstood requirements.
When onboarding new team members	Executable specs document intent better than static requirements.
Regulated or compliance-heavy projects	Provides auditable traceability from requirement to test.

Key concepts

Concept	Description
The Three Amigos	A structured conversation between business, development, and testing to reach shared understanding before implementation.
Gherkin Format	Given / When / Then syntax that bridges natural language with automation. Readable by non-technical stakeholders.
Executable Specifications	Acceptance criteria written as automated tests that run in CI and always reflect the current system behaviour.
Living Documentation	The automated test suite becomes up-to-date documentation that evolves with the codebase.

Common pitfalls

Pitfall	How to avoid it
Writing tests without business involvement	Always include the Product Owner or BA in Three Amigos. If they can't attend, defer the story.
UI-specific tests that break on every layout change	Write acceptance tests at the business-rule layer (API or service level) where possible.
Focusing on tooling before requirements	Start with conversation and examples. Tooling comes after the team understands what to build.
Treating ATDD as a testing activity only	It is a whole-team practice. Developers must be involved in writing and maintaining the specs.
Too many acceptance tests	Focus on the "happy path" and critical edge cases. Don't exhaustively cover what unit tests should catch.

NZ context

New Zealand's regulated industries—finance, health, and government—often require requirements traceability for audit and compliance purposes. ATDD provides a natural mechanism for this: each acceptance test directly traces back to a business requirement, and every failure is a signal that the system no longer meets agreed criteria.

For teams working under the Privacy Act 2020 or Financial Markets Conduct Act, ATDD examples can include data-privacy and consent scenarios, ensuring compliance is built in from the start rather than bolted on later.

Career level guidance

Level	Focus	What to practise
Junior	Participation & comprehension	Attend Three Amigos sessions, ask clarifying questions, read Gherkin scenarios, and learn how acceptance tests map to story criteria.
Senior	Facilitation & automation	Facilitate Three Amigos, challenge ambiguous requirements, write Gherkin scenarios, automate acceptance tests, and mentor juniors on testable thinking.
Test Lead	Strategy & organisational adoption	Roll out ATDD across squads, choose and maintain tooling, coach Product Owners on writing testable acceptance criteria, and measure defect escape rates pre vs post adoption.