← Back to Insights Quality Assurance

Acceptance Testing: How to Get Software Sign-Off Right

20 October 2026 · Ramin Amini

Development is finished, the system tests are green – and still the business department refuses to sign off. Or worse: it signs off, and only in production does it become clear that key workflows do not work the way they are needed. Acceptance testing is meant to prevent exactly that. This article shows how to prepare and run acceptance tests so that they end in a sound decision – not an argument about expectations.

What acceptance testing does – and what it doesn't

Acceptance testing is the last test level before software goes into production. Unlike component, integration and system testing, its main question is not whether the software is technically built correctly, but whether it is fit for purpose: can future users do their jobs with the system, and are the agreed requirements met?

That leads to an important distinction. Acceptance tests do not replace thorough testing at the earlier levels. If acceptance testing still uncovers fundamental technical defects, the problem lies in the test strategy, not in acceptance. The goal is confidence in the overall system – defects found here should be the exception, not the rule.

The main types of acceptance testing

The term is often equated with business users testing the software. In practice – and in the ISTQB syllabus – several forms are distinguished, and their importance varies from project to project:

• User acceptance testing (UAT): business users check whether the software supports their real-world workflows.
• Operational acceptance testing: operations and IT check backup and restore, user administration, maintainability, monitoring and emergency procedures.
• Contractual and regulatory acceptance testing: evidence that contractually agreed criteria and legal or industry-specific requirements are met.
• Alpha and beta testing: for off-the-shelf software and products, selected users give feedback in their own or a real environment before a broad rollout.

Operational acceptance testing in particular is often forgotten. An application that convinces the business but cannot be properly backed up, monitored or updated is not ready for operation.

Step 1: Define acceptance criteria early and measurably

The most common source of conflict at sign-off is criteria that are only discussed at the end. Different expectations then collide, and each side feels it is right. Acceptance criteria therefore belong at the beginning – in the requirements, the user stories or the specification.

Good acceptance criteria are unambiguous, testable and agreed with the business. "The search should be user-friendly" is not a basis for testing; "clerks can find a case by reference number, name or date" is. Our article The Underrated Success Factor: Clean Requirements explains how to write requirements that can be tested later.

Also define what happens to the deviations you find. A proven approach is to classify defects – for example "blocks acceptance", "acceptance with conditions" and "can be fixed in operation" – together with a clear rule on which defect situation still allows sign-off.

Step 2: Derive test cases from real business processes

Acceptance test cases should not work through individual screens but cover complete workflows from the user's perspective: from receiving an application through review and approval to the decision, from quotation through order to invoice. Only then does it become clear whether interfaces, permissions and data flows work together.

• Business-critical processes first: what happens most often in daily work or causes the greatest damage if it fails is tested most thoroughly.
• Plan special cases deliberately: expiring deadlines, cancellations, deputy rules or incorrect input are more common in practice than expected.
• Consider roles: each workflow is tested with the permissions the respective role actually has in production – not with an administrator account.

Test cases should be clear enough for business users to run them without testing experience, and precise enough that a result can be clearly rated as passed or failed.

Step 3: Prepare environment, data and people

Acceptance testing needs an environment that comes as close as possible to production in configuration, interfaces and authorisation concept. Test data should reflect realistic cases; personal data is anonymised or generated synthetically.

Organisational preparation is at least as important. The business users who are supposed to test usually have a full workload. Their time must therefore be agreed with their managers early and firmly scheduled. A short introduction to the application, the test cases and defect reporting prevents valuable test time from being lost to questions.

Step 4: Execute, document, retest

During the test phase, clear coordination is essential: who tests which cases by when? Where are deviations recorded, and who assesses them? A short daily check-in between the business, test management and development keeps the defect situation transparent and speeds up decisions.

• Record deviations reproducibly: steps, expected and actual result, data, role and screenshot.
• Separate defects from change requests: not every piece of feedback is a defect. New wishes go through change management, otherwise scope grows uncontrolled.
• Retest fixes: fixed defects are checked again, and affected workflows are secured with regression tests.

Step 5: Make the acceptance decision

At the end there is a decision, not a mood. It is based on an acceptance report summarising which test cases were run, which deviations remain open, how they are classified and which risks exist for operation. This leads to one of three recommendations: acceptance, acceptance with conditions including defined fixes and deadlines, or refusal of acceptance with a concrete justification.

For externally commissioned software, acceptance often has contractual significance as well – for example for payments or the start of warranty periods. That makes careful documentation of test results, open issues and conditions all the more important. The contractual consequences in each individual case should be clarified with your legal department or legal counsel.

Acceptance testing in agile projects

In Scrum there is no single big sign-off at the end of the project but many small ones: acceptance criteria belong to every user story, and the product owner assesses increments in the sprint review. However, this does not fully replace acceptance testing before go-live. Before a larger release, a bundled business acceptance test of end-to-end processes is still worthwhile, especially when several teams or systems are involved. Recurring acceptance scenarios can be partly automated – our guide Introducing Test Automation: A 6-Step Guide shows how.

Common mistakes in acceptance testing

• Clarifying criteria only at the end: sign-off then becomes a negotiation rather than a test.
• Involving the business too late: anyone who sees the software for the first time in acceptance testing discovers fundamental misunderstandings too late.
• Planning too little time: acceptance is often misused as a buffer and shrinks when development takes longer.
• Forgetting operations: backup, permissions and monitoring are not checked.
• Signing off without documentation: verbal approvals help no one when questions about open issues arise later.

Conclusion

Acceptance testing is the moment that shows whether an IT project fulfils its purpose. With acceptance criteria agreed early and made measurable, test cases drawn from real business processes, well-prepared business users and a documented decision, a point of conflict becomes a plannable milestone. Read Why Quality Assurance Decides Project Success to see how quality assurance contributes to success across the whole project.

Frequently asked questions about acceptance testing

Who performs acceptance testing?

Primarily the future users from the business department, supported by test management, which organises test cases, environment and defect reporting. Operational acceptance tests are carried out by IT operations or administration.

What is the difference between system testing and acceptance testing?

System testing checks whether the overall system implements the specified requirements in a technically correct way and is usually carried out by the development or test team. Acceptance testing checks whether the system is fit for its intended use and is owned by the business and operations.

What happens if defects are found during acceptance?

The deviations are documented and rated by severity. Depending on the defect situation, acceptance is granted, granted with conditions including defined fixes, or refused with a justification. Fixed defects are then retested.