Acceptance testing is logically the last test level in software development and assesses whether a system is good enough to be put into use. Its purpose is to build confidence, not to find bugs: quality has to be built in earlier rather than tested in at the end. Teams that follow shift left and involve testers early save a great deal in the end.
Key Takeaways
- The goal of acceptance testing is to build confidence, not to find bugs. Teams that use it as their final quality gate pay the highest bug-fixing costs of the entire development process.
- Testers who help shape requirements from the start make it more likely that the team builds the right thing, because they bring in testability, edge cases and non-functional criteria before the first line of code is written.
- An oversized acceptance test is usually a symptom of missing transparency about what earlier test levels have already covered, not a sign of thoroughness.
- Agile acceptance testing and classic acceptance testing share the same goal. They differ in how deeply the test is woven into the development process and how early everyone involved works together.
What Is Acceptance Testing For?
Acceptance testing checks whether a test object is good enough to be put into use, seen from the perspective of the customer, the business side or the users. Logically, it is the last test level, after component, integration and system testing.
The key difference from system testing is the point of view. System testing looks at the integrated system from the perspective of the vendor or contractor. Acceptance testing switches sides and takes the user’s view.
Acceptance testing has a different job from the test levels before it: it builds confidence rather than hunting for bugs. At its core, the goal is to find no more bugs, because the test object does what it’s supposed to do.
Florian Fieber, co-author of the German book “Basiswissen Abnahmetest”, calls acceptance testing the most exciting test level. It shows particularly well what you can get right or wrong in testing.
Agile and Traditional Acceptance Testing: Same Goal, Different Setting
In terms of their goal, agile acceptance testing and classic acceptance testing are the same thing. The difference lies in how well the activities are woven into the development process.
In an agile setting, acceptance testing is built into the development process. Built-in quality, shift left and collaboration between roles are much stronger there. As a result, acceptance happens earlier, more collaboratively and more efficiently.
In a classic waterfall or V-model project, acceptance testing follows the same principle but faces different conditions. It often happens very late. Requirements, development and testing are decoupled, and testing only joins in at a late stage.
The underlying idea is identical. What changes is how well it works: the more closely acceptance is woven into the process and the collaboration, the more efficiently it can play out.
Shift Left: Why Timing Decides Success
When testers get involved in acceptance determines almost everything else. It decides how well acceptance testing can mesh with development.
The bad case looks like this: development has been running for ages, the requirements were written long ago, the implementation is being polished. Preparation for acceptance only starts a few weeks before delivery. That’s exactly what you want to avoid.
There’s a common fallacy behind this. Acceptance testing is logically the last test level, but that doesn’t mean you have to deal with it last.
You don’t have to wait until system testing is done and the delivery has arrived before you think about test planning, test scope and test cases. That work can be done much earlier.
If the tester is on board from the start, they join the requirements process. Ideally not as a guest asking for a say, but in a setup where working on requirements together is the norm. That takes organizational groundwork, which is easier to find in an agile environment than in separate silos.
What Makes Good Acceptance Criteria
A good requirement is, first of all, testable. The testing perspective has to shape the requirement early, otherwise it can’t be tested at all.
Testers bring their own way of looking at things. They ask questions, think outside the box, consider edge cases and want to know exactly where the line between two cases runs. That precision uncovers gaps before any code exists.
Testability also takes a certain completeness. A user story needs not only the happy paths, but also the edge cases and the negative cases.
Non-functional requirements matter at least as much. Usability, accessibility, security and performance can be anchored early through suitable acceptance criteria. This is real added value a tester can bring to the team.
The ideal case: before the first line of code is written, business analysis, testing and development arrive at a shared understanding. Acceptance criteria and test cases written up front provide concrete examples and make it more likely that the right thing gets built.
The Ideal Acceptance Test Doesn’t Need to Happen at All
An acceptance test that tries to test quality into the product comes at the worst possible moment. That’s exactly what you don’t want.
In practice, acceptance tests are often far bigger than necessary. The reason rarely lies in the test object itself. It lies in a lack of trust and transparency. If you don’t know what has already been tested, you test everything again, just to be safe.
That mistrust grows with distance. When a supplier or another development department throws software over the fence, acceptance tests tend to balloon. In the end, quality gets tested in at the very last moment.
“The ideal acceptance test is one that doesn’t have to happen at all. The goal is to build confidence, and I don’t build confidence by finding bugs. The bugs should be found before that.”
(Florian Fieber)
The relative cost of fixing defects makes the point. Acceptance testing is a poor place to uncover and fix lots of bugs this late. It can be effective as the last line of defense. Efficient it is not.
That doesn’t mean you stop testing during acceptance. You keep testing, but what you test works. When the earlier stages run cleanly and transparently, acceptance can be relaxed instead of a last-minute scramble to fix things.
How Testing Expertise and Business Knowledge Come Together
Acceptance tests are often carried out by business experts who know the product from the user’s side but aren’t testing specialists. How much testing expertise you need depends on what the acceptance test is supposed to achieve.
If the acceptance test is still expected to uncover bugs in earnest, it needs both perspectives. Not every user is familiar with test techniques, different kinds of tests and suitable test data. In that case, the testing perspective and the user perspective have to work together.
If it’s purely about building confidence, things look different. A beta test or some form of exploratory testing may be enough, with users working with the test object in their normal jobs instead of running through formal test cases. Then deep testing expertise isn’t strictly necessary.
It also matters whether users see the test object for the first time during acceptance testing or have followed the development all along. In the second case, all that’s left is a final check.
Test First: How ATDD and BDD Support Acceptance Testing
Why write acceptance tests before any code exists? Because test-first approaches shift acceptance to the left and sharpen the shared understanding before implementation starts. Acceptance test-driven development (ATDD) and behavior-driven development (BDD) are the main tools for this.
Test cases written before implementation provide concrete examples. Those examples make the requirements easier to understand and support the implementation, because developers know more precisely what they’re working toward.
For this to work, business analysis and acceptance testing have to come together. Business analyst and tester remain different roles, but their work belongs together and they should collaborate closely.
Modeling Business Processes and Business Rules as Test Support
In acceptance testing, models do double duty: they specify the test object and provide the basis for deriving expected behavior. BPMN is a natural fit for modeling business processes.
Business rules can be captured with DMN (Decision Model and Notation) and decision tables. From models like these, you derive which paths through a critical business process need to be covered.
The value of modeling goes beyond specification. From a testing perspective, it helps you identify expected behavior and focus on the paths that matter most to the business.
The following overview shows the focus areas of the Certified Tester Acceptance Testing syllabus, on which “Basiswissen Abnahmetest” is based:
| Focus Area | Content |
|---|---|
| Fundamentals | Why acceptance testing matters, efficient design through collaboration and early testing |
| Collaboration | Bringing business analysis and acceptance testing together, roles of business analyst and tester |
| Test First | ATDD and BDD, embedded in a suitable process |
| Quality Criteria | Non-functional criteria, with a closer look at usability, IT security and performance |
| Modeling | Business processes with BPMN, business rules with DMN and decision tables |
| Tools | A short section on test tools |
Frequently Asked Questions
How does acceptance testing differ from system testing?
System testing examines the integrated system from the perspective of the manufacturer or contractor. Acceptance testing switches sides and evaluates, from the perspective of the client, business users, or end-users, whether the test object is good enough for deployment. It is logically the final test level following component, integration, and system testing and is not primarily aimed at finding defects.
Is an agile acceptance test different from traditional acceptance testing?
Not in terms of its goal. Acceptance tests, whether called “Akzeptanztest,” “acceptance testing,” or “Acceptance Test,” all follow the same principle. The difference lies in how deeply the activities are embedded in the development process: In an agile environment, built-in quality, shift left, and collaboration among roles are more pronounced. In waterfall or V-model projects, requirements, development, and testing are often decoupled, and acceptance comes late.
Can you wait until after system testing to begin preparing for acceptance testing?
You can, but doing so means missing out on the most important opportunities. While acceptance testing is logically the final test level, this does not mean it has to be the last thing you address. Test planning, test scope, and test cases can be developed much earlier. If preparation doesn’t begin until a few weeks before delivery, it’s virtually impossible to integrate it with the development process.
Why do acceptance tests often end up being much more extensive than necessary in practice?
Most often, there’s a lack of transparency regarding what has already been tested at the earlier test levels. Those who don’t know this will test everything again just to be safe. This mistrust grows particularly strong when a vendor or an external development department simply hands over software without further review. Bloated acceptance testing is thus a symptom of a lack of trust, not a sign of thoroughness.
What are the benefits of involving testers as early as the requirements definition phase?
Testers make requirements testable. They ask about the boundary between two test cases, add edge cases and negative cases, and anchor non-functional criteria such as usability, accessibility, security, and performance through appropriate acceptance criteria. If a shared understanding emerges between business analysis, testing, and development before the first line of code is written, the likelihood of building the right thing increases.
Do business users need testing expertise for acceptance testing?
That depends on what the acceptance testing is intended to achieve. If the goal is to seriously uncover defects, the testing and user perspectives must work together, because not every user is familiar with test techniques, test conditions, and appropriate test data. If the goal is purely to build trust, beta testing or exploratory testing in the normal workday (without formal test cases) is often sufficient.
What do ATDD and BDD contribute to acceptance testing?
They shift acceptance testing to an earlier stage and sharpen the shared understanding before implementation. Test cases created before the code is written provide concrete examples and support the implementation because developers know more precisely what they are working with. A prerequisite is that the activities of business analysis and acceptance testing are integrated. The roles remain distinct, but their content is intrinsically linked.
What is the purpose of modeling in acceptance testing?
Models serve a dual purpose: They specify the test object and provide the basis for deriving expected behavior. Business processes can be mapped using BPMN, business rules using DMN and decision tables. This determines which paths of a business-critical process must be covered and which paths need to be tested specifically.
