Acceptance Testing
Acceptance testing is the test level that focuses on deciding whether to accept a system. System testing asks whether the whole system meets its specification; acceptance testing asks whether it is fit for the people and the organisation that will use it, and ready to deploy. The ISTQB Foundation syllabus (CTFL v4.0) describes it as focused on validation and on demonstrating readiness for deployment, ideally performed by the intended users.
Example: a school has had an online gradebook built. The vendor’s system tests have passed; now teachers enter a term of realistic grades, the office prints report cards and the IT team restores the data from a backup. When these checks meet the criteria in the contract, the principal accepts the system.
Why it matters
A system can pass every system test and still be the wrong system: a requirement was misunderstood, a business process was never written down, or the product works with test data but not with real roles, volumes and operations. Acceptance testing is the last planned check before customers, staff or regulators find these gaps, while there is still time to decide: release, release with known issues, or wait.
Finding defects is usually not its main goal: finding many serious defects at this stage is a major project risk and often means that earlier levels missed something. The tester’s role changes too: others judge the result, and your job is to give them testable criteria, a realistic environment and evidence they can trust.
The forms of acceptance testing
The ISTQB syllabus names five main forms: user acceptance testing, operational acceptance testing, contractual and regulatory acceptance testing (one form in the syllabus, two different checks in practice), alpha testing and beta testing. They differ in who performs them and which question they answer. Custom software for one customer usually needs contractual acceptance and UAT; a product for a market, whose future customers cannot all be asked in advance, usually adds alpha and beta testing, while its own staff and business partners may still run UAT.
- User acceptance testing (UAT): intended users check that they can do their real work with the system, with their own processes and roles and with realistic data, in a real or simulated operational environment.
- Operational acceptance testing (OAT): operations or system administration staff check that they can keep it running: backup and restore, installation and upgrade, disaster recovery, user management and monitoring.
- Contractual acceptance testing: checks custom-built software against the acceptance criteria in the contract, which should be agreed when the contract is signed.
- Regulatory acceptance testing: checks the system against the laws and regulations it must follow; a regulator sometimes witnesses or audits the results.
- Alpha testing: potential or existing customers, operators or an independent test team, not the developers, use the product at the developing organisation’s site.
- Beta testing: customers use the product at their own locations and on their own devices, with or without an alpha first, and find defects tied to environments the team finds hard to reproduce.
| Form | Performed by | The question it answers | Who decides |
|---|---|---|---|
| User acceptance (UAT) | Intended users, in a real or simulated operational environment | Can we do our real work with it? | Business owner of the process or product owner |
| Operational (OAT) | Operations or system administration staff | Can we run, back up, restore and support it? | Head of operations or service owner |
| Contractual | Users or independent testers | Does it meet the acceptance criteria in the contract? | Customer representative named in the contract |
| Regulatory | Users or independent testers, sometimes witnessed by a regulator | Does it follow the laws and regulations that apply? | Compliance owner, and the regulator or an auditor where required |
| Alpha | Customers, operators or an independent test team, at the developer’s site | Does it work for people outside the development team? | Product owner or product manager |
| Beta | Customers at their own locations, on their own devices | Does it work in real environments the team finds hard to reproduce? | Product owner or product manager |
Based on the ISTQB Foundation syllabus, which counts contractual and regulatory acceptance as one form. Decision owners differ between organisations: agree them in the test plan or the contract.
Acceptance criteria are the test basis
Every acceptance test needs a test basis that defines "acceptable". For a user story it is the acceptance criteria: the conditions an implementation must meet to be accepted by stakeholders. UAT also draws on the business processes the users follow, contractual acceptance uses the contract’s criteria, regulatory acceptance the regulation itself, and OAT the operational requirements, such as backup and recovery procedures.
Good criteria are agreed before the work is built, so that acceptance is a check rather than a negotiation, and they are testable: a user, a developer and a tester who read one reach the same verdict. Writing them as rules or as Given/When/Then scenarios has its own lesson later in the roadmap; here, learn to spot a vague one.
- Vague: "Leave balances update correctly." Testable: "When a manager approves a request, the annual-leave balance falls by the working days requested, a half day counting as 0.5."
- Vague: "Backups are in place." Testable: "Last night’s backup restores to a clean server with the same number of employees and requests that production had when the backup was taken."
Try it: Acceptance Criteria Generator Try it: AI Acceptance Criteria Reviewer
Who decides acceptance
Acceptance is a decision, and it belongs to the people who carry the business risk of using the system, not to those who built or tested it. Name the decision maker for each form in the test plan or the contract before testing starts.
The outcomes are: accept; accept with conditions, such as known defects with an agreed workaround or fix date; or reject until the defects are fixed and retested. Record the decision with the version tested, the open defects and the conditions; many teams call this record the sign-off.
- UAT: the business owner of the process or the product owner.
- OAT: the head of operations or the service owner.
- Contractual: the customer’s representative named in the contract.
- Regulatory: the compliance owner, plus the regulator or an auditor where the rules require it.
- Alpha and beta: the product owner or product manager, who decides on the general release.
- The tester: gives evidence and a recommendation (results, open defects with their severity, that is how much harm each one does, and the remaining risk) but never accepts on the business’s behalf.
Worked example: accepting an HR leave module
A vendor has built a leave-management module for a company’s HR portal. The contract lists six acceptance criteria and names the HR director as the person who accepts. There is no alpha or beta: the module is built for one customer. All six criteria come from the contract, but each one is checked in the form that fits it, by the people best placed to judge it. After three days the company’s QA lead hands over the record below; its decision line is the HR director’s.
- AC-1, AC-2 (UAT): four HR staff and three line managers submit, approve, reject and cancel requests for three days on a staging copy with anonymised data.
- AC-3 (contractual): the company’s QA team, independent of the vendor, prepares employees with known balances and checks every balance after approval, half days included.
- AC-4, AC-5 (OAT): IT operations restores last night’s backup to a clean server and reconciles the nightly payroll export with the source.
- AC-6 (regulatory): the HR compliance officer checks leave types and records against the labour-law requirements that apply to the company.
Acceptance record: leave module 1.0, build 1.0.4, staging
ID Form Result Evidence
AC-1 UAT Passed UAT-01..UAT-06
AC-2 UAT Passed UAT-07..UAT-10
AC-3 Contractual Failed DEF-112 (Major)
AC-4 OAT Passed OPS-01 restore log
AC-5 OAT Passed OPS-02 payroll export totals
AC-6 Regulatory Passed COMP-01 compliance checklist
Open defect: DEF-112 (Major): half-day leave is deducted as 1 day, not 0.5
QA recommendation: accept after DEF-112 passes confirmation testing
Decision (HR director): conditional acceptance, go-live after the fixTry it: Requirements → Test Cases Try it: User Story → Test Scenarios
Common mistakes
- Treating acceptance as a second round of system testing, re-running scripted test cases instead of letting users check their own processes.
- Starting without agreed, testable acceptance criteria, so that the project ends in an argument about what was promised.
- Forgetting OAT: the users are satisfied, but nobody checked backup, restore, monitoring or upgrades.
- Starting UAT on an unstable build or with unrealistic data, wasting users’ limited time on defects that system testing should have caught.
The QA perspective
A tester’s acceptance work starts early: in story refinement or contract review, check that every criterion is testable and that every form the project needs has a decision maker. Before UAT, prepare the environment, realistic data and user accounts, write short scenarios in the users’ language, and confirm that the build has passed system testing.
During acceptance, support rather than lead: help users record results and report defects, triage what they find with the product owner (a defect, a change request or a training issue), and keep a traceable record of which criterion passed with which evidence. Finish with a summary and a clear recommendation, and record the decision with the version tested.
Practice exercise
Plan acceptance for scheduled food orders
A food-delivery company is adding scheduled orders to its app: customers choose a delivery time up to seven days ahead, restaurants receive the orders in their tablet app, and the company’s operations team runs the servers. Assume that a consumer-protection rule requires the full price, including the delivery fee, to be shown before payment. Plan the acceptance testing.
- List the forms of acceptance testing that apply and those that do not, with a reason.
- For each form that applies, name who performs it and who decides.
- Rewrite "Scheduled orders arrive on time" as a testable criterion.
Show the model answer
UAT, because restaurant staff and support agents are intended users with their own work to do: restaurant staff accept and prepare scheduled orders in their real workflow, and support agents find and change one. The feature’s product owner decides.
OAT: operations checks the job that releases orders to restaurants, its alerts, waiting orders after a server restart, and the rollback plan. The head of operations decides.
Regulatory: the compliance or legal team checks that the full price appears before payment on every route to payment, and decides. Contractual: only if a contract with restaurants or a partner sets criteria for this feature.
Alpha and beta, because the app serves a market: staff outside the development team order as customers at the company’s site, then a small group of customers in one city tries it on their own phones. The product owner decides on release.
Testable: "The order appears in the restaurant’s tablet app 45 minutes before the chosen delivery time, give or take one minute, and the customer sees the chosen time on the confirmation screen and in the order history." It checks what the system controls, when the order is released, not the courier’s journey. The numbers are the product owner’s choice; what matters is that there are numbers.
Frequently asked questions
Is UAT the same as acceptance testing?
No. UAT is one form of acceptance testing, the one performed by intended users. Acceptance testing also includes operational, contractual and regulatory acceptance, and alpha and beta testing. In everyday speech many teams say "UAT" for the whole acceptance phase; when the difference matters, ask which forms are actually planned.
Do testers perform acceptance testing?
Sometimes. Contractual and regulatory acceptance testing is often performed by users or by independent testers, and alpha testing can be run by an independent test team. In UAT, testers usually prepare and support while users perform the tests. In every case the decision to accept belongs to the business side.
Does acceptance testing happen only at the end?
No. In iterative and agile development, stories are accepted against their criteria during each iteration, and alpha or beta testing can run before a general release. A traditional project may also have a formal acceptance phase before go-live. A bought, off-the-shelf product may go through acceptance testing when it is installed or integrated.
What should the acceptance summary contain?
The results per acceptance criterion with their evidence, the open defects with their severity and the risk they leave, and a recommendation with any conditions, such as "release after confirmation testing of one Major defect". The decision maker signs on that basis; fixed defects then need confirmation testing and regression testing.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- Certified Tester Acceptance Testing (CT-AcT)ISTQB's specialist syllabus on acceptance testing: user, contractual and regulatory acceptance testing, alpha and beta testing, and how testers work with product owners and business analysts.
Practise with Mutqan tools
Generate Given/When/Then acceptance criteria and a definition-of-done checklist from a user story.
Review acceptance criteria for testability, completeness and ambiguity, with rewritten suggestions from Mutqan AI.
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Derive end-to-end test scenarios from a user story, including alternate and exception flows.
Derive test scenarios from functional requirements with coverage mapping.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.