The system test is performed by the QA or test team and checks whether the system meets the technical requirements and specifications. User acceptance testing, on the other hand, is conducted by real end users or business representatives and assesses whether the software meets the business processes and acceptance criteria of the organization. UAT typically takes place after system testing and is the last testing phase before go-live.
What is user acceptance testing (UAT)?
User acceptance testing (UAT) is a testing phase in which real end users or business representatives manually verify software under realistic conditions. The goal is to confirm that the system meets the agreed-upon acceptance criteria and can be approved for production use.
UAT typically takes place after system testing — once technical testing has been completed — and serves as the final quality gate before go-live. Unlike developer tests, the focus is not on the technical correctness of the code but on the question: “Does the software meet the requirements and expectations of users and the business?”
In the ISTQB context, UAT is a subtype of acceptance testing and is often referred to as Business Acceptance Testing (BAT) when sign-off is performed by business representatives rather than end users.
Modern teams increasingly complement manual UAT phases with automated UI tests — both for web and for desktop and mobile applications. For repetitive regression checks and well-defined business workflows, these can significantly reduce — or in many cases completely replace — the manual testing effort.
Practical examples of user acceptance testing with QF-Test
QF-Test helps teams automate UAT scenarios and make acceptance test cases efficiently reusable.
Practical recommendations:
- Automate acceptance-relevant workflows: Turn typical UAT scenarios into automated UI tests — whether for web, Java/Swing, JavaFX, SWT/RCP, Windows desktop, or mobile applications. These run reliably at every release without requiring manual involvement from business teams, permanently reducing acceptance test effort.
- Map critical business processes as end-to-end scenarios: Model complete user workflows as end-to-end tests that verify the entire user journey — from login to completion — across all integrated systems.
- Structure functional acceptance tests: Use QF-Test to align functional tests precisely with acceptance criteria and document them in a traceable way between test managers and business teams.
- Write test results back to test management: With the test management integration, UAT results are automatically transferred to your issue tracking system and are immediately available for the acceptance decision.
- Align UAT scenarios with your test strategy: Make sure your UAT scenarios fit the overarching test strategy and specifically cover risk areas and business-critical workflows.
Goals of user acceptance testing
- Validate acceptance criteria: Verify that the delivered software meets the agreed requirements and business processes
- Confirm the release decision: Make an informed go/no-go decision based on real user scenarios
- Identify issues from a user perspective: Uncover usability problems and business gaps that technical tests cannot detect
- Minimize risks before go-live: Prevent critical failures before real users are affected
- Build acceptance within the business: Actively involve business representatives and build confidence in the new system
- Create acceptance documentation: Produce sign-off records that serve as formal proof of software acceptance
These goals apply to all stakeholders: testers, developers, project managers, and business decision-makers.
How does user acceptance testing work?
- Requirements analysis and test basis: Acceptance criteria are derived from user stories, functional specifications, or requirement documents
- Test planning: Test scope, roles, schedule, and test environment are defined; test cases are created or carried over from previous test phases
- UAT environment preparation: A production-like test environment with realistic test data is set up
- Test execution by end users: Key users or business representatives execute prepared test scenarios and document results and deviations
- Defect management: Defects found are evaluated, prioritized, and handed off to the development team for resolution
- Acceptance or remediation: After successful test execution, formal sign-off is granted; critical defects trigger additional remediation cycles
UAT is not a one-time activity but an iterative process. Especially in agile projects, it is conducted sprint-by-sprint or alongside each release — with close coordination between business, QA, and development. The quality of the test environment and the clarity of the acceptance criteria are the key success factors.
Conducting user acceptance testing
When it’s used
UAT is used when a release is approaching go-live and the technical test phases (unit tests, integration tests, system test) have been completed. Typical situations include new system rollouts, major releases, migration projects, and regulatory sign-offs — for example in financial services, insurance, or medical technology.
Prerequisites
Before a UAT can begin, the following conditions must be met: a stable, production-like test environment with representative test data, finalized and agreed acceptance criteria, available key users or business representatives, and a completed system test with no open critical defects.
Step-by-step approach
Start by deriving acceptance criteria from the requirements and creating test scenarios from a user perspective. Prepare the UAT environment and test data, brief the business testers, and execute the tests. Document results and deviations in a structured way, classify defects by priority, and initiate remediation. The process concludes with a formal sign-off record and the release decision.
Common pitfalls
UAT phases are often planned too late or heavily compressed on the timeline. Another common pitfall is the absence of concrete acceptance criteria — without a clear baseline, acceptance becomes subjective and leads to disputes. Insufficient test data or a non-representative test environment also significantly reduce the validity of UAT results.
Combining with other methods
UAT works well in combination with automated regression tests so that already-accepted functionality does not need to be fully re-tested manually. For GUI applications, automated UI tests with QF-Test are a particularly efficient complement — across web, Java, JavaFX, SWT, Windows desktop, and mobile interfaces. Stable, well-defined acceptance workflows can be fully automated, permanently reducing the burden on business teams. In agile projects, UAT supplements the definition of done for each user story. The ATDD approach (Acceptance Test-Driven Development) links acceptance criteria to concrete tests already during development, significantly reducing remediation effort during UAT.
Benefits of user acceptance testing
- High relevance assurance: Only functionality that works in real-world use is approved — not just technically correct code
- Early user involvement: Business teams are actively included, which increases acceptance of the new software
- Reduction of production defects: Issues that would only surface after go-live are identified and resolved before release
- Clear acceptance documentation: UAT records provide legal and procedural certainty during software handover
- Better communication between IT and business: The shared testing process promotes mutual understanding and sharpens requirements for future releases
Challenges and solutions in user acceptance testing
Limited availability of key users: Testers from the business side are often tied up in their day-to-day work and difficult to free up for UAT phases. UAT time slots should be scheduled early in the project plan and formally agreed upon with the business. Automated regression tests reduce the manual effort per release and ease the burden on those responsible for testing.
Unclear acceptance criteria: When requirements are too vaguely defined, acceptance becomes subjective and leads to disputes between business and IT. Acceptance criteria should already be formulated as SMART criteria during the requirements phase — specific, measurable, achievable, relevant, and time-bound.
Non-representative test environment: Defects that only occur in production — for example due to different configurations or data volumes — go undetected in UAT. Invest in a UAT environment that matches the production environment as closely as possible, including realistic test data and identical configuration.
Time pressure at the end of the project: UAT is frequently planned as the final step and gets compressed when earlier phases run late. Anchor UAT as a fixed milestone with explicitly planned buffers for remediation cycles, and use automated tests to reduce manual testing effort.
Best practices
- Plan UAT early, not just at the end of the project: Establish it as a fixed milestone in the project plan — with realistic time allocated for remediation cycles
- Define acceptance criteria before UAT begins: Work with business teams to formulate clear, measurable acceptance criteria to avoid subjective sign-off discussions
- Use test automation strategically: Automate recurring UAT scenarios for critical business processes so that regression tests run efficiently and without manual effort at every release
- Structure communication between IT and business: Regular sync meetings and a clear defect management process ensure that issue tickets are quickly evaluated and prioritized
Conclusion
User acceptance testing is the final quality gate before every software release, ensuring that only software that is not just technically correct but also acceptable to real users and the business goes into production. With clearly defined acceptance criteria, a production-like test environment, and strategic use of test automation, UAT can be conducted efficiently and reliably. QF-Test helps teams automate UAT scenarios, write test results back to test management tools, and sustainably bridge the gap between technical development processes and business requirements.
Frequently asked questions (FAQ)
What is the difference between UAT and system test?
UAT and system test are often confused — but they test from different perspectives.
What is the difference between UAT and system test?
UAT and system test are often confused — but they test from different perspectives.
Can UAT be automated?
Manual UAT tests are time-consuming — but not everything needs to be tested by hand.
Can UAT be automated?
Manual UAT tests are time-consuming — but not everything needs to be tested by hand.
Yes, parts of UAT can be automated very effectively — especially recurring acceptance tests for critical business processes. Exploratory testing and the subjective user perspective still require human judgment. For clearly defined, stable workflows, automated UI tests with QF-Test can fully replace manual UAT execution — regardless of whether the application is a web, Java, JavaFX, SWT, Windows desktop, or mobile application. Once implemented, they run reliably at every release without any involvement from business teams.
How is UAT conducted in agile projects?
Agile projects approach UAT differently than classic waterfall projects.
How is UAT conducted in agile projects?
Agile projects approach UAT differently than classic waterfall projects.
In agile projects, UAT does not happen only at the end of the project but is conducted sprint-by-sprint or alongside each release. Acceptance criteria are formulated as part of each user story — for example following the ATDD approach — and signed off with the business at the end of a sprint. This continuous involvement of business teams shortens feedback loops and significantly reduces the effort required for final acceptance phases.
Interested in QF-Test?
Tell us about your project, and we’ll personally show you how QF-Test can support you.
