User acceptance testing, usually shortened to UAT, is the point at which authorised business users verify that a system supports the agreed processes and outcomes. It is not a substitute for developer testing or quality assurance. It answers a different question: can the business accept this release for its intended use?
UAT works only when requirements and acceptance criteria already exist. Without them, the exercise becomes a collection of opinions about whether the system “feels right”.
How UAT differs from other testing
| Activity | Main question | Typical owner |
|---|---|---|
| Developer testing | Does the component behave as designed? | Development team. |
| Quality assurance | Does the release meet the specification across normal, negative and regression scenarios? | Tester or QA team. |
| Technical specialist testing | Does the system meet defined performance, security, accessibility or recovery conditions? | Appropriate specialist. |
| User acceptance testing | Does the release support the business process and agreed acceptance criteria? | Authorised business users. |
A release should not be handed to users for basic fault-finding. UAT participants need a stable environment and a build that has already passed the supplier’s planned testing.
Define the scope before UAT begins
State which release, features, integrations, user groups and processes are being accepted. Identify anything deliberately excluded or unavailable. This prevents a disagreement about whether a missing item is a defect, a deferred requirement or outside scope.
Entry conditions may include:
- the agreed release is deployed to the UAT environment;
- supplier testing is complete and evidence is available;
- known defects are listed with their impact;
- test accounts, roles and data are ready;
- integrations or controlled substitutes are available;
- acceptance criteria and scenarios have been approved;
- participants have time and instructions.
Choose participants who understand the work
UAT should include representatives of the roles affected by the release. A manager cannot reliably accept a detailed operational workflow they never perform. Equally, a user should not decide alone whether a wider business control or contractual requirement is satisfied.
Name the acceptance owner who resolves conflicting feedback and gives the formal decision. Other participants provide evidence; the owner applies the agreed acceptance rules.
Test end-to-end business scenarios
Good UAT scenarios follow real work rather than isolated buttons. A customer-portal scenario might begin with an account invitation, continue through document upload and review, and end with the customer seeing the outcome. Include handoffs, notifications, permissions and records created along the way.
Each scenario should state:
- the starting data and system state;
- the user role;
- the steps to perform;
- the expected result at each important point;
- the evidence to retain;
- the acceptance criterion being tested.
Include exceptions and negative conditions
UAT is not complete after the ideal path succeeds. Test rejected approvals, missing information, duplicate submissions, expired links, permission boundaries and recovery from user mistakes. These scenarios often determine whether a system is safe and usable in daily operations.
Do not expect UAT users to invent all edge cases during the session. The requirements and earlier testing should provide a planned set of scenarios.
Prepare realistic, controlled test data
Test data should represent the records, volumes and variations users will encounter. Include different statuses, roles, boundary values and exceptions. Protect personal or commercially sensitive information and do not copy live data casually into a test environment.
Where an integration cannot be used normally, document the limitation. A simulated response may test the workflow, but it does not prove that the live integration will operate correctly.
Record defects and requirement gaps separately
A defect is a failure to meet an agreed requirement. A requirement gap means the agreed requirement did not cover what the business now realises it needs. A new preference is a proposed change. Mixing the three makes scope and sign-off difficult.
| Finding | Example | Typical treatment |
|---|---|---|
| Defect | A user with the approved role cannot complete the documented action. | Fix and retest according to severity. |
| Requirement gap | A real exception was not represented in the agreed process. | Assess impact, agree change and update acceptance. |
| Enhancement | A participant would prefer an additional filter. | Add to the prioritised backlog unless essential to acceptance. |
| Training issue | The feature works, but the user did not understand the agreed process. | Improve guidance, terminology or training as appropriate. |
Agree severity and retesting
Define which findings block acceptance, which may be accepted with a workaround and which can be deferred. Severity should reflect business impact, not the effort required to fix the issue.
After a fix, rerun the failed scenario and any related critical paths. A change to an approval rule may affect notifications, reporting and permissions, not only the screen where the defect appeared.
Set clear exit criteria
UAT is complete when the agreed evidence supports a decision, not when the calendar says the testing period has ended. Exit criteria may require:
- all critical scenarios completed;
- every acceptance criterion recorded as passed, conditionally accepted or not accepted;
- blocking defects resolved and retested;
- remaining defects documented with owners and dates;
- operational, training and support prerequisites confirmed;
- formal acceptance or rejection by the authorised owner.
Limitations of UAT
UAT cannot prove that the system is secure, scalable or recoverable unless those qualities have their own specialist tests. It cannot compensate for incomplete requirements, a poor test environment or unrepresentative participants. It also does not guarantee that no defect remains.
Its value is disciplined business evidence: the agreed users completed the agreed scenarios under documented conditions and the organisation made an informed acceptance decision.
Questions to put to a supplier
- What testing will be complete before the release enters UAT?
- How are acceptance criteria traced to UAT scenarios?
- Which environment and integrations will be used?
- How will defects, requirement gaps and enhancements be separated?
- What support will be available during UAT?
- Which evidence will be included in the final acceptance record?
Practical next step
Select one critical business process and convert it into an end-to-end UAT scenario with a named user role, starting data, expected results and acceptance criteria. If that cannot be done clearly, improve the requirements before scheduling the wider UAT phase.