Acceptance Test Driven Development (ATDD): A Complete Guide
Ambiguous acceptance criteria are among the most expensive defects in delivery, since your team pays for them twice: Once in wasted implementation, and again in rework. Acceptance criteria may read clearly to everyone and still mean something slightly different to each contributor. Rework, missed sprint commitments, and UAT rejections all start there. Acceptance test-driven development (ФЕВВ) is the correct methodology to fix the issue.
Acceptance test-driven development is a collaborative practice where your product owner, developers, and testers agree on acceptance examples before implementation starts.
ATDD works at the feature level and pairs with TDD, which covers unit-level design. BDD overlaps heavily with ATDD, since both rely on collaborative discovery and Given-When-Then scenarios.
Most of the work happens in requirements discovery. Teams that open a Gherkin file before discussing the feature skip the part that prevents expensive rework.
Acceptance scenarios should describe business behavior, while API endpoints and table names belong in step definitions.
Tooling splits into requirements platforms, executable specification frameworks, and test management systems. Reqnroll replaced SpecFlow for .NET after Tricentis ended support at the close of 2024.
This guide covers what ATDD is and where it differs from TDD and BDD, then shows the cycle through a worked password reset example. It also elaborates on tools, the Agile practices, and the habits that keep it running.
What Is Acceptance Test Driven Development (ATDD)?
Acceptance test driven development is a collaborative approach where your product owner, developers, and testers agree on acceptance examples before a feature gets built. Because those examples describe the behavior the finished code has to show, they guide implementation from the first commit.
You will see acceptance test driven development ATDD written both ways across QA documentation, and both spellings mean the same practice. “Driven” is the operative word in that definition. Tests written after a feature ships had no influence on its design, so that work counts as plain acceptance testing. ATDD puts the examples first, and your developers build toward them.
Practitioners often summarize the cycle as four steps, known as Discuss, Distill, Develop, and Demo. Your team discusses the requirement, distills it into specific examples, then develops against those failing examples before demonstrating the result.
Why ATDD Is a Requirements Practice
ATDD is a requirements practice because its main output is a set of agreed rules, and the tests come from those rules. Consider the shipping requirement again: until someone asks how large an order qualifies and whether discounts change the total, the rule stays incomplete. Traditional delivery raises those questions during implementation or after release, when answering them means changing code. ATDD pulls the same questions into refinement.
ATDD vs TDD vs BDD
All three approaches use tests or examples to guide development, though each one answers a different question about the system. Search results routinely conflate ATDD acceptance test driven development with the other two, so a side-by-side comparison helps.
Aspect
ATDD
TDD
BDD
Primary focus
Business acceptance criteria and customer requirements
Technical design and implementation correctness
Behavior and shared domain language across roles
Who participates
Product owner, developers, testers
Developers
Product owner, developers, testers, analysts
Abstraction level
Externally observable business behavior
Internal code units such as classes and functions
Domain behavior expressed in business language
Typical test format
Given-When-Then scenarios or acceptance criteria
Unit tests with assertions
Given-When-Then scenarios focused on behavior
Primary outcome
Agreement on what “done” means
Clean, maintainable, well-designed code
Documentation that stays accurate as the system changes
TDD and ATDD differ mainly in scope. In test driven development, a developer writes a failing unit test, adds the minimum code that makes it pass, then refactors. ATDD works one level up, at the feature. A single acceptance test such as “customer receives free shipping at €50” can cover several TDD cycles for pricing and cart eligibility.
BDD and ATDD overlap heavily in modern practice. Both emerged around vague requirements and poor communication between business and delivery, and both use collaborative discovery with Given-When-Then examples. The vocabulary differs: ATDD talks about acceptance criteria, BDD about behavior and executable specifications. Teams practicing one routinely borrow techniques from the other.
Your product owners, developers, and testers should all be able to track the coverage behind every requirement. aqua cloud, an AI-driven test and requirement management platform, orchestrates data, acceptance criteria, and test cases in one place, so every example stays interconnected. aqua Intelligence, grounded in your own project documentation, drafts test cases from those requirements in seconds and writes them in your domain language. Every plan also includes unlimited free Guest licences, so business analysts and stakeholders can read acceptance criteria and coverage reports without taking a paid seat. Teams moving to aqua save up to 60% of the time they spend on QA management, which pays for the refinement hours ATDD asks for. Bidirectional Jira sync keeps refinement outcomes and test results aligned in both directions, while Azure DevOps and Confluence integrations carry acceptance criteria through to implementation.
Draft executable test cases from your agreed acceptance criteria in seconds with aqua’s AI
Acceptance test driven development practice rests on a small set of ideas that hold whatever tooling your team picks: business, development, and testing agree on scope before code starts, and concrete examples replace wording open to more than one reading.
Collaboration Comes Before Implementation
ATDD brings the business, development, and testing perspectives into one conversation before the work starts. Teams usually call the pattern the Three Amigos, though the group may also include a designer or an architect. Consider whether “€50 orders” means “at least €50” or “more than €50.” The two readings produce different cart logic, so someone has to decide between them. Refinement is where that decision belongs.
Examples Make Rules Specific
Agreeing that “orders over €50 qualify for free shipping” is easy. The harder question is whether a €55 order with a €10 discount qualifies. Working through cases like that forces precision, and your product and delivery teams converge on one vocabulary. Specification by Example builds on the same idea, since real scenarios express business rules that prose leaves open to interpretation.
Acceptance Gets Agreed Before Code
Your team settles what “done” looks like while the requirement is still editable. That agreement becomes the target for developers and the checklist for testers. Automated acceptance test driven development adds executable checks on top. Some teams automate every scenario while others keep a manual set, and both practice ATDD.
The ATDD Process: Step by Step
AI-generated image.
The ATDD cycle runs from a rough user need through to permanent regression coverage. Our seven-step breakdown is one practical reading of that flow, since the practice itself prescribes no fixed number of stages.
1. Start With a User Need
Every cycle begins with a statement of what your users need, whether that arrives as a user story or a one-line backlog item. For example: “Registered customers receive free standard shipping when their eligible order exceeds €50.” At this stage the requirement lacks the detail needed for confident implementation. Your team agrees on the problem here, and the solution comes later.
2. Discuss It Collaboratively
The Three Amigos examine the story from business, implementation, and testing perspectives. Product states the intent, a developer names what the code cannot decide from the wording, and a tester names the boundaries and error paths. Product says “free shipping above €50,” the developer asks which subtotal to calculate, and the tester asks what happens at exactly €50. Product answers both questions in the session, and your team writes the answers down before anyone leaves.
3. Distill Abstract Rules Into Concrete Examples
With the assumptions on the table, your team converts wording into cases anyone can verify. Take “orders over €50 qualify for free shipping” and test the wording against real carts. The rule might then become: “Free standard shipping applies when the eligible merchandise subtotal after discounts is at least €50.” The agreed examples then read as follows:
Cart contents
Expected outcome
€50 in eligible items
Free shipping
€49.99 in eligible items
Paid shipping
€75 before a €30 discount
Paid shipping
€60 with €15 in excluded items
Paid shipping
The third row is where your team discovers whether “exceeds €50” meant “more than” or “at least.”
Acceptance criteria and acceptance tests work at two levels of detail, and teams frequently conflate them:
Acceptance criteria
Acceptance tests and examples
Purpose
Define the conditions for acceptance
Prove those conditions with specific cases
Form
Business rule
Specific input or context, plus the expected result
Example
Orders of €50 or more get free shipping
€50 free shipping; €49.99 paid shipping
Example Mapping separates the two for the same reason. Rules state what has to hold, and examples show what that looks like for one particular cart.
4. Formulate Acceptance Tests
Once the examples are agreed, express them in a format that can guide implementation. Given-When-Then works well here because it separates context, action, and outcome:
Scenario: Free shipping at threshold
Given a registered customer
And their eligible cart subtotal is €50
When they proceed to checkout
Then standard shipping should be free
Scenario: Shipping below threshold
Given a registered customer
And their eligible cart subtotal is €49.99
When they proceed to checkout
Then standard shipping should not be free
Gherkin syntax remains optional throughout. Your developers and testers only need to read the same example and reach the same conclusion about the behavior to build. These scenarios then become the working contract between product and delivery.
5. Implement the Functionality
Development starts with the acceptance tests already failing, since the feature does not exist yet. Your developers choose whatever implementation approach fits, such as TDD at the unit level or pair programming. The acceptance specifications define the target throughout.
6. Make the Tests Pass
As implementation progresses, the agreed scenarios start passing one by one. When all of them pass, the feature meets acceptance criteria that your team settled before any code existed. Arguments about whether the work is finished stop here, because the definition was fixed upfront.
7. Retain the Tests as Regression Coverage
Finally, keep the passing acceptance tests as regression coverage, on the condition that they evolve with the requirements they specify. An outdated scenario can still fail correctly while documenting a rule your product owner changed two sprints ago. Automated scenarios flag implementation drift as soon as they run. Manual scenarios report nothing until someone deliberately re-runs them.
Roles and Responsibilities in ATDD
ATDD depends on three perspectives contributing at the right moment, and each one owns a different question. The practice collapses when your team treats it as “QA writes Gherkin scenarios.”
Perspective
Usually held by
Questions they raise
What they own
Business
Product owner, business analyst, domain expert
Does this discount apply? What happens for premium members?
The “what” and the “why”
Development
Developers, architects
Do we calculate before or after tax? What if the payment gateway is unavailable?
The “how,” plus technical constraints on the “what”
Testing
Testers, QA engineers
What happens at exactly €50? What about an expired token used twice?
The “what if” and the completeness of examples
Acceptance Test Driven Development Example: Password Reset
A worked acceptance test driven development example shows what the cycle produces. Product brings a familiar story: “As a customer, I want to reset my password so that I can regain access to my account.”
The story reads as complete until your team examines it:
Does the system reveal whether an email address exists?
How long does the reset link stay valid?
Can someone use the same link twice?
What happens when a customer requests a second reset before using the first?
Are existing sessions revoked after the password changes?
Which password policy applies to the new password?
None of these are edge cases. Each one describes core behavior that the original story left unspecified, so a developer would otherwise decide it alone.
Through discussion the team lands on a business rule: A reset token can be used exactly once and expires after 30 minutes. Three scenarios make that rule testable:
Scenario: Valid token within time limit
Given a reset link was created 10 minutes ago
When the customer submits a valid new password
Then the password changes
And the reset token becomes invalid
Scenario: Expired token
Given a reset link was created 31 minutes ago
When the customer attempts to use it
Then the password remains unchanged
And the customer is informed that the link expired
Scenario: Reused token
Given a reset token has already been used
When the customer attempts to use it again
Then the request is rejected
And the customer is informed that the link is no longer valid
Your developers now know to generate a token that dies after 30 minutes, then check its age and used status before allowing a reset. Testers know what to verify, and product knows what customers will experience. Once the scenarios pass, they stay in the suite so a later refactor cannot quietly remove token expiry.
The acceptance criteria are about defining the details in an unambiguous way. Crucially, they're great for allowing the team to communicate and organise around functionality and make sure they share the same interpretation of a user story.
Earlier ambiguity detection: Vague requirements come out in refinement, so a 15-minute discussion replaces three days of misdirected implementation.
Agreement across roles: Business, development, and QA settle intended behavior before any code exists.
Testable requirements: Acceptance criteria built from examples with observable outcomes are simple to verify.
Less requirement-driven rework: Misunderstood requirements are among the most expensive sources of defects, and ATDD exposes them while they are still wording.
Built-in regression coverage: Automated acceptance examples keep checking expected behavior after later changes.
Reduced scope creep: Specific scenarios tell your developers exactly what behavior to implement.
Faster feedback loops: Problems appear in discussion, so the loop tightens from weeks in UAT down to hours in refinement.
Challenges and Limitations of ATDD
Upfront time in refinement: Collaborative specification adds time to requirement discussions, and teams accustomed to starting code immediately find the pace slow. Since the payoff comes later, you need organizational agreement that early clarity is worth the investment.
Cultural change: The practice fails when product throws requirements over the wall, or when developers talk to testers only after implementation. Collaborative habits take longer to build than technical skills.
Risk of over-specification: Some teams try to document every possible input combination before development starts, which is analysis paralysis. Aim for clarity on key behavior, and stop well short of a 100-page specification.
Tooling can distract from the conversation: Teams that debate Cucumber syntax and CI configuration before discussing the requirement automate behavior no one has agreed on.
Not every criterion deserves automation: Certain scenarios are expensive to automate, rarely change, or are quicker to verify by hand. Effort spent automating them returns little.
Scheduling the Three Amigos: Getting the right people into one room is hard for distributed teams across time zones, and postponed sessions erode the benefit quickly.
It does not replace other testing: ATDD answers whether a feature matches agreed acceptance criteria. Performance, security, usability, and exploratory testing all remain your team’s responsibility.
Acceptance Test Driven Development Tools and Frameworks
Acceptance test driven development tools fall into three categories, and each one serves a different part of the cycle.
Collaboration and Requirements Tools
These handle the upstream work, from user stories and acceptance criteria through to approvals and change history. Every agreed example needs a home and a link back to its parent requirement. Jira, Azure DevOps, and a dedicated test management tool such as aqua cover this space. aqua holds the chain from requirement to acceptance criteria to test case to execution result, with approvals and audit history included.
Executable Specification Frameworks
These convert agreed examples into runnable checks. Readability is their shared strength, because non-developers can read the scenarios and challenge them.
Framework
Ecosystem
Best fit
Cucumber
Java, JavaScript, Ruby
Teams standardizing on Gherkin scenarios
Reqnroll
.NET
Gherkin-based executable specifications for modern .NET projects
Robot Framework
Python, cross-platform
Keyword-driven tests for mixed-skill teams
FitNesse
Java, .NET
Established suites in long-running products
Reqnroll is the actively maintained successor to the discontinued SpecFlow project, which lost vendor support at the end of 2024. Any .NET team starting today should therefore skip SpecFlow tutorials. Every framework here automates scenarios your team agreed on beforehand, and requirements management stays with the tools in the previous category.
Test Management Systems
Once your team runs acceptance scenarios at scale, ownership and traceability become the daily problem. Which requirement does this failure affect, and who owns the scenario? A test case management tool answers both by centralizing requirements, acceptance criteria, test cases, execution results, and defects. Coverage reporting then tells your team which requirements still have no scenarios attached.
Pick the stack that fits the workflow your team already runs.
The acceptance test driven development diagram below moves through four phases, with feedback loops connecting each phase to the one before it.
Discovery phase: Requirements Two Amigos discussion Business rules identified Examples created
Specification phase: Given-When-Then scenarios Acceptance criteria documented Test cases formalized
Implementation phase: Failing acceptance tests Development using TDD Passing acceptance tests
Maintenance phase: Regression suite Continuous verification Documentation that stays accurate
The phases run iteratively and never strictly in line. When examples reveal an unclear rule, your team returns to discovery. An unexpected failure sends it back to the specification, and changed acceptance criteria restart the cycle from the top.
When writing stories, get the "three amigo's" to join up — architects for the holistic view, devs for the "how" and testers to tie it all up nicely. Your task is to give the group context for what needs to be done, moderate the discussion and ultimately write down what they need to have in the story.
Acceptance test driven development in Agile teams needs no new events, because refinement, planning, and review already cover the discussion. What changes is the content of those meetings. The Scrum Guide treats Definition of Done as a commitment and says nothing about a Definition of Ready. Rows here therefore mix Scrum events with practices some teams add.
Scrum activity or practice
Where ATDD fits
Backlog refinement
Your team defines examples for each story and identifies the rules behind them
Definition of Ready, where teams use one
A story qualifies once agreed, testable examples exist, so vague work stays out of the sprint
Sprint planning
Estimates improve because developers know the exact behavior, and testers can prepare data and environments
Daily Scrum
Failing acceptance scenarios can expose blockers affecting progress toward the Sprint Goal
Sprint review
Stakeholders watch passing scenarios demonstrated and know exactly which behavior works
Retrospective
Your team measures how often examples were defined late or revised mid-sprint
Definition of Done
Completion means every agreed acceptance scenario passes, which removes subjective judgement
ATDD works best when it changes meetings your team already runs. Adding a separate specification workshop on top of refinement produces the opposite result, because the extra meeting becomes the first thing dropped in a busy sprint. For a wider view of how examples feed test design, our guide to Agile test case design techniques covers the techniques that pair well with ATDD.
How aqua Supports ATDD From Refinement to Execution
aqua cloud supports ATDD by holding requirements and their acceptance examples in one system, then linking each example to the tests and results that verify it. Because refinement outcomes, test cases, and execution history stay in one place, your team can answer coverage questions without opening three tools.
Requirements and acceptance criteria in one place. aqua’s requirements management module stores user stories together with their acceptance criteria. Test cases link to them automatically, so anything left uncovered shows up on the requirements view.
Gherkin generation from requirements. aqua Intelligence drafts test cases in BDD format directly from a requirement. Your team then reviews a first version of each scenario during refinement.
Bidirectional Jira sync. Stories refined in Jira arrive in aqua with their acceptance criteria attached. Results flow back to the ticket afterward, so product sees which scenarios pass.
Automation and evidence. Jenkins, Ranorex, and the REST API integration feed automated results back into aqua. The Capture extension meanwhile records manual runs with video and screenshots.
When an acceptance test fails, your team sees the parent requirement, the owner, the execution history, and any linked defect on one screen. That screen is also the record auditors ask for.
Boost your QA testing efficiency by 80% with aqua’s capabilities
Structure the discussion with Example Mapping. The technique organizes refinement around the story, the rules governing it, an example for each rule, and the open questions. Working in that order keeps the session moving, because unresolved questions are recorded for later and stop stalling the discussion. Timebox each story, then feed the output directly into your acceptance tests.
Describe observable behavior in your scenarios. A scenario that reads “When I send POST /api/v2/cart and query table cart_items” documents your architecture. A scenario that reads “When the customer adds the product to their cart, then the product appears in the cart” documents the business rule. Keep endpoints and table names in step definitions, where they belong.
Choose the cheapest test interface that proves the behavior. Business acceptance rarely requires a browser, so service-level or API-level checks are usually the better default. They run faster, break less often, and still verify what product asked for. Some scenarios genuinely need UI verification, and those are worth their cost.
Keep scenarios independent. Each scenario should set up its own context, exercise one behavior, and verify one outcome. Dependence on earlier scenarios makes failures painful to debug, and a scenario covering ten behaviors hides which rule broke. Your suite grows larger this way, and it also becomes far easier to trust.
Automate based on value. Prioritize scenarios that run every sprint or cover core business flows. Leave low-value examples manual until your team has bandwidth to automate them properly. Suites built for total coverage tend to stay permanently red.
Maintain specifications when requirements change. An acceptance scenario that no longer matches the agreed rule becomes misleading documentation, even while it passes. So when product changes a rule, update the scenario in the same sprint and check that it still links to its requirement. Teams that skip this maintenance accumulate documentation describing an older version of the product.
ATDD depends on collaborative discovery, agreed examples, and traceability from business intent through verification. aqua cloud, an AI-powered test and requiremeте management solution, covers all three in one platform. Define requirements and acceptance criteria with your team, then let aqua Intelligence draft complete test scenarios from your project’s own documentation. Every acceptance example links back to its parent requirement, so your team keeps bidirectional traceability at any scale. aqua is ISO 27001 certified and DORA compliant, so the acceptance evidence your team collects holds up in an external audit without a separate reporting exercise. More than 200 companies and 35,000 users across 26 countries already run their QA this way. Run scenarios manually or through 10+ native automation integrations, including Jenkins, Ranorex, JMeter, SoapUI, REST API, PowerShell, UnixShell, and MSSQL or Oracle databases. The Capture integration then records every execution with video and screenshots for your audit history.
Reach complete ATDD traceability and 100% test coverage with project-aware AI
Try aqua for free
Conclusion
ATDD moves acceptance from a final check into an early conversation. When your product owner, developers, and testers agree on specific examples before implementation, ambiguity comes out while the requirement is still editable. Those examples then work as specification, verification, and documentation at once. The practice does ask for cultural change, refinement time, and tooling that traces a requirement through to execution. With those in place, your team spends far less of each sprint rebuilding features that were misunderstood the first time.
TDD is a developer practice built on unit tests that shape internal design. ATDD works at the feature level, where business examples define observable behavior. Your developers often run several TDD cycles underneath a single acceptance test.
Is ATDD the Same as BDD?
They overlap heavily in modern practice. Both rely on collaborative discovery and Given-When-Then examples. BDD emphasizes behavior and shared domain language across the delivery cycle. ATDD centers on acceptance criteria and the point at which a feature counts as done.
Who Writes Acceptance Tests in ATDD?
Your whole team contributes. Product owners define the business outcome, developers raise technical constraints, and testers push on edge cases. A tester or business analyst usually writes the final wording, though the examples themselves come out of the shared discussion.
What Are the Main Benefits of ATDD?
Earlier detection of vague requirements, agreement across roles, testable acceptance criteria, and less requirement-driven rework. Automated examples also stay in your suite as regression coverage that documents intended behavior for anyone joining your team later.
Which Tools Support Acceptance Test Driven Development?
Cucumber, Reqnroll, and Robot Framework convert agreed examples into executable specifications. Requirements, coverage, and traceability belong in test management platforms such as aqua cloud. Jira or Azure DevOps handle the story-level workflow around them.
Does ATDD Require Automating Every Scenario?
No. Automate the scenarios that run each sprint or cover core business flows, and keep rare or expensive checks manual. Teams that automate everything usually accumulate a maintenance load heavy enough to push them off the practice.
When Should Your Team Define Acceptance Tests?
Shortly before development starts, during backlog refinement. Define them earlier and the details go stale before coding begins. Leave it later and your team writes tests for code that already exists.
Enhancement of the aqua product is Martin’s main responsibility and biggest mission. His expertise covers ITIL Process Consulting, Change Management, Quality Assurance, Quality Management, and Requirements Management. Martin works in QA services for regulated industries for more than 18 years being an irreplaceable leader at…
Nurlan, a QA Coordinator & Quality Standards Officer, takes pride in orchestrating seamless QA operations. His expertise in coordinating QA-focused projects and integrating QA solutions has consistently yielded top-tier client satisfaction. Aside from a full-time QA coordinator, Nurlan's role involves creating compelling content that educates…
Pavel, a Quality Assurance Consultant and Author, brings deep expertise to solving complex testing challenges. His background in software development has helped organizations transform their QA practices from reactive to proactive. Beyond consulting, Pavel develops best practice guides and case studies for aqua cloud that…
Home » Best practices » Acceptance Test Driven Development (ATDD): A Complete Guide
Do you love testing as we do?
Join our community of enthusiastic experts! Get new posts from the aqua blog directly in your inbox. QA trends, community discussion overviews, insightful tips — you’ll love it!
We're committed to your privacy. Aqua uses the information you provide to us to contact you about our relevant content, products, and services. You may unsubscribe from these communications at any time. For more information, check out our Privacy policy.
X
🤖 Exciting new updates to aqua AI Assistant are now available! 🎉
