User acceptance testing: how to run UAT with control

What UAT is for

UAT is not simply another round of technical testing. Its purpose is to establish whether the delivered change works well enough for the intended business use and whether the people accountable for acceptance are prepared to take it forward.

The exact process varies by organisation. On a small change, UAT may involve a short set of critical scenarios and a simple sign-off. On a larger programme, it may involve several business areas, controlled test data, formal defect triage and multiple approval points. The control should match the risk and complexity of the change.

Start with requirements and acceptance criteria

Good UAT begins before test execution. Each important requirement or business outcome should be clear enough that somebody can decide what evidence would demonstrate acceptance.

Avoid treating a requirement list and a test-case list as unrelated documents. The useful control is traceability: every important requirement should have one or more relevant tests, and every test should make clear what it is intended to prove.

This helps expose two common gaps:

• a requirement that has never been tested;
• a test case that exists but is not linked to a meaningful business requirement.

Acceptance criteria should be specific enough to support a decision. “Works as expected” is usually too vague. State the business behaviour, condition or outcome that must be demonstrated.

Build test cases around business use

A UAT test case should describe a realistic user or business scenario, the action to perform and the expected result. It does not need to reproduce the detail of a technical test script.

For each case, record enough information to identify it consistently, link it to the requirement, assign an owner or tester and capture the result.

Useful statuses might include:

• Not started
• In progress
• Passed
• Failed
• Blocked

Keep the status set small. The purpose is to make the current position understandable, not to create a vocabulary exercise.

Control defects and retesting

A failed UAT case does not automatically mean the release must stop. The important question is what failed, how serious it is, what business impact it creates and what will happen next.

Record defects separately from test cases so that one defect can be tracked through investigation, resolution and retest without losing the original test evidence.

Useful defect information includes:

• defect ID and short description;
• related test case;
• severity or business impact;
• owner;
• current status;
• resolution or workaround;
• retest result.

Severity should reflect business consequence, not frustration. If your organisation already has an agreed defect model, use it.

Assess release readiness using evidence

A release-readiness view should bring together the small number of facts that matter to the acceptance decision. Typical questions include:

• How many planned UAT tests have been completed?
• What proportion have passed?
• Are any critical or high-impact defects still open?
• Are important requirements missing test coverage?
• Are blocked tests hiding unresolved risk?
• Have agreed retests completed?
• Are the right people prepared to accept the residual position?

A percentage alone is not enough. A 95% pass rate can still hide one failure that makes the release unacceptable.

Use the metrics to focus discussion, then apply judgement to the actual business impact. Record any exposure that continues beyond the release as a residual risk with a named owner. The project risk management guide explains how to distinguish current and residual risk and plan a response.

Record sign-off clearly

Sign-off should record the decision that was made, by whom and on what basis. It is useful to distinguish between:

• accepted for release;
• accepted with known limitations or actions;
• not accepted.

If a release is accepted with open defects or follow-up actions, record who owns them and what will happen next. Do not let “signed off” become shorthand for unresolved work disappearing from view.

Confirm who has acceptance authority before the final decision is due. The stakeholder management guide can help identify who can approve, block or materially change the release decision.

Common UAT mistakes

The problems are usually organisational rather than technical:

• starting UAT before requirements or acceptance criteria are clear;
• creating tests without linking them back to business requirements;
• recording failed tests but not controlling the related defects;
• counting tests while ignoring severity and business impact;
• allowing several spreadsheets to become competing records;
• treating sign-off as a ceremonial final email rather than an evidence-based decision;
• carrying open actions into release without a named owner.

A simple UAT sequence

1. Confirm the scope of UAT and who has acceptance authority.
2. Review the requirements and acceptance criteria.
3. Create and link the UAT test cases.
4. Prepare the test environment, data and testers.
5. Execute tests and record results consistently.
6. Log defects and agree their severity, owner and route to resolution.
7. Retest resolved defects and failed scenarios where required.
8. Review readiness using test completion, pass results, coverage and open-defect evidence.
9. Record the acceptance decision and any residual actions.
10. Retain the final evidence with the project record.

The sequence can be scaled down for a simple project. Add control where it reduces uncertainty.

This guide and workbook are practical project-delivery aids. They do not replace your organisation's testing standards, security controls, regulatory requirements, release governance or professional judgement.