What Is Acceptance Testing?
Acceptance testing is the final test level before a software system goes live. It decides whether the system is fit for its intended purpose. Technically oriented test levels such as system testing check against specifications from the developer’s point of view. Software acceptance testing takes the perspective of the people who will later pay for, operate, or use the system.
An acceptance test is the point at which the customer decides whether to accept the system. What changes from earlier test levels is the vantage point. The developer has already judged whether the system was built correctly. Now the customer judges whether the right thing was built at all.
In theory the sequence is quickly told: the customer tests, nods with satisfaction, the contract is fulfilled, everyone is happy. In practice it often looks different. Crashes, confusing interfaces, functions that are missing or implemented differently than imagined. Instead of satisfaction, there are discussions about what was originally meant. Acceptance testing is the moment that reveals whether the preceding months were put to good use.
Acceptance Test and Acceptance Criteria: Clarifying the Terms
Swipe right or use the arrow keys to see the full graphic.
In practice, “acceptance test” and “acceptance criteria” are sometimes used interchangeably. They carry different emphases within the same activity, though. An acceptance test is the formal process of determining whether a deliverable meets agreed conditions, often with contractual consequences. A passed acceptance test can trigger payment milestones, initiate the transition to maintenance or release the go-live.
Acceptance criteria, by contrast, are the specific, measurable conditions a system must satisfy to be considered acceptable. They form the test basis for the acceptance test. The distinction matters in practice: a team can define acceptance criteria long before an acceptance test runs. A project that treats acceptance only as a contractual box to tick risks a system that is formally accepted and quietly worked around in daily use.
What Are the Types of Acceptance Testing?
The ISTQB Foundation Level syllabus names six main types: user acceptance testing, operational acceptance testing, contractual acceptance testing, regulatory acceptance testing, alpha testing, and beta testing. In my projects, the first two carry most of the weight.
User acceptance testing (UAT) is the type I meet most often in projects. Some teams use business acceptance testing as another name for it, others treat that as a separate type. Representative end users test the software in scenarios that reflect their real working day. The goal is practical usability from the user’s perspective; technical completeness was the job of system testing. UAT passes when the users confirm they can do their work with the software.
Operational acceptance testing (OAT) checks production readiness from an IT operations standpoint: backup and recovery, monitoring, maintainability, performance under load, and correct integration into the customer’s infrastructure. Teams frequently forget OAT. Because it is not functional testing, nobody on the business side feels responsible for it, and its checks often slip into production.
Contract Acceptance Testing verifies that all contractually agreed requirements have been fulfilled. Its outcome is tied directly to contract terms and specified acceptance criteria. Precision in the requirements documentation therefore weighs more heavily here than almost anywhere else.
Regulatory acceptance testing applies in regulated industries: medical devices, automotive, aviation, financial services. Before a system may go into operation there, relevant standards and compliance obligations must be satisfied. Acceptance involves not just the customer, but regulatory bodies or certification authorities.
Alpha and beta testing are specialized types used primarily for product software. Alpha tests take place at the developer’s site with a controlled group, beta tests put the software into the hands of selected external users in their real environment. Both are less formalized than classical acceptance tests. In return, they provide signals about a product’s market readiness that a controlled test environment could never produce.
Test Basis and Test Objectives
The test basis for acceptance testing consists of the customer’s or user’s business requirements: business processes, user stories, epics and use cases. In migration projects, the documentation or user manual of the legacy system may also serve as test basis. A proven system is often the most precise available evidence of how the new one should behave.
The objective is to determine, from the customer’s point of view, whether the system meets the functional and non-functional requirements. The customer decides whether the supplier implemented their ideas and concepts as intended. The outcome is formal acceptance: the project concludes or moves into maintenance, payments flow, training and go-live follow.
Non-functional requirements belong to the acceptance scope as well. Acceptance checks performance, usability, security, and availability before go-live, with the same kind of criteria as the functions.
How Should Acceptance Criteria Be Defined and Tested?
Customer and supplier must agree on the acceptance criteria before testing begins. They describe in measurable terms under what conditions the software qualifies as acceptable. Missing or vague criteria are a dependable source of disputes between customer and supplier.
“The software must be user-friendly” fails as an acceptance criterion because nobody can check it. “All core processes on the agreed process list must be executable without error” works. A good acceptance criterion is concrete, verifiable, and unambiguous.
Two formats are common for writing criteria down, and the ISTQB Foundation Level syllabus names both. Scenario-oriented criteria follow the Given/When/Then pattern known from BDD and describe a flow. Rule-oriented criteria are a checklist or a table that maps inputs to expected outputs. Testing the criteria then means at least one test case per criterion, positive and negative, each naming the criterion it covers. The acceptance meeting can then go through the result criterion by criterion.
The outcome of acceptance testing carries far-reaching consequences, so unclear criteria can make for heated conversations. The air in some acceptance meetings turns noticeably thick when customer and supplier hold different views on what counts as passed. That tension is avoidable: work out the criteria together and early, rather than interpreting them for the first time in a dispute.
Which Test Environment Does Acceptance Need?
The test object is the integrated overall system as it will run in production. Interfaces to other systems are already connected and active. The application is tested from the outside, in the same way users will interact with it every day.
Test results are only reliable when the tests run in the customer’s final infrastructure or in a fully production-equivalent environment. Only there do the incompatibilities and side effects show up that stay invisible in a divergent setup. When a system goes live for the first time, teams sometimes use the future production environment directly for the acceptance tests. Virtualization and container technologies have made such environments much easier to set up.
Who Writes the Test Cases for Acceptance?
Business requirements are often documented in plain text. Deriving meaningful test cases from those texts is not a trivial task. Least of all when the testers are domain experts or end users with no background in structured testing.
Methods such as equivalence partitioning or boundary value analysis are typically unknown to business-side testers. So is the knowledge of how to document, structure and evaluate test cases. A brief introduction at the start of acceptance test activities pays off noticeably here. A few hours of guidance can substantially raise the quality of testing done by an entire business unit.
The approach that holds up best combines both worlds: structured test design methods and experience-based test cases that mirror the users’ typical working scenarios. The domain experts know their processes, the testers know their methods. Together they cover the real workflows and the edge cases that structured methods bring to light.
Test Data
The customer should provide, or at least control, the test data for acceptance testing. Anonymized production data is a strong choice: it reflects realistic scenarios and carries the quirks of real data sets that are hard to reproduce artificially. Alternatively, teams reuse the test data management from system testing. Whatever the source, the test data must represent the future user perspective as closely as possible.
How Does an Acceptance Test Proceed, from Planning to Sign-Off?
In a classical project, acceptance runs as a phase with a clear sequence. Planning sets scope, participants, schedule, environment, and the entry criteria: completed test levels, fixed defects, delivered documents, everything that has to be in place before acceptance starts. Preparation covers the acceptance criteria, the test cases derived from them, test data, and a briefing for the business testers. Execution follows the agreed test procedure: each test case runs against the integrated system, the tester logs the result per case and per criterion, and every deviation becomes a defect report with a severity.
The acceptance test report brings the results together: what the testers covered, which criteria passed, which defects remain open and how severe they are, and where the result deviates from the agreement. On that basis the customer takes the acceptance decision. Three outcomes are common: accepted, accepted with conditions (open defects with agreed deadlines), or rejected with a defined retest. Customer and supplier document and sign the decision, because it usually triggers payment, warranty periods, and the handover to operations.
Which steps apply, and how formal each one is, differs from project to project. Regulated environments and fixed-price contracts need the full sequence with signatures; an in-house product may compress it to a demo, a checklist, and a short written note. Even the short form records who checked which criterion and with which result.
Automation: Once at the End or Every Sprint?
In traditional projects, teams run the acceptance test only once. Automation rarely pays off there, because a single run does not justify the investment.
Agile projects work differently: acceptance tests run every sprint, sometimes daily, and without automation the team cannot repeat them that often. Behavior-Driven Development (BDD) connects the business acceptance criteria directly to executable tests: frameworks like Cucumber or Robot Framework let domain experts write acceptance criteria in readable language and run them automatically. Business requirement and executable test then share one text, which keeps them from drifting apart. Few projects need a dedicated acceptance testing tool on top: test cases, results, and defects live in the project’s test management tool, automated acceptance tests in a BDD framework.
How Does Acceptance Work in Agile Projects?
In Scrum and Kanban, acceptance shifts to the sprint level. Two things tend to get mixed up here: the Definition of Done describes the quality state every increment must reach, and it applies to the whole product; the ISTQB syllabus treats it as the agile name for exit criteria. Acceptance criteria describe what a single user story is supposed to deliver in business terms. You need both, but neither replaces the other. Teams that practice acceptance test-driven development (ATDD) write the acceptance tests before implementing the story, so the tests double as executable requirements.
Continuous feedback from the customer or Product Owner complements the classical end-of-project acceptance test and takes most of the load off it. Automated regression tests safeguard accepted increments, and contractual, regulatory, and release acceptance remain as manual steps in their own right. The sprint rhythm keeps the interval between two rounds of feedback short, so the customer sees deviations within one sprint.
Where Acceptance Goes Wrong in Classical Projects
In classical projects, the same difficulties recur in acceptance testing. Non-functional requirements went unaddressed until the acceptance phase and now reveal their performance or usability problems. Gaps in requirements engineering surface at precisely this point, with maximum consequences, because there is barely any time left to correct them. Time pressure is high, the project is meant to close soon, the irritability of everyone involved rises accordingly. And the domain testers often lack the basics of structured testing.
Early involvement helps most against these problems. The sooner customers and end users join the development process, the fewer surprises remain for acceptance. The Agile Manifesto makes this collaboration a principle: business people and developers must work together daily throughout the project.
In Practice
Acceptance tests rarely unfold as smoothly as theory suggests. Some projects treat acceptance as three clicks and a handshake. Other customers set up professional test centres for it. The range is enormous, and so are the consequences of both extremes.