User acceptance testing checks whether new software works for the people who will use it. It puts real work through the finished system before launch.
A screen can work exactly as designed and still fail at work. A refund may save, yet post the wrong tax value. A job may close, yet never reach the invoice queue. UAT finds these gaps before bespoke software goes live.
This guide shows how to plan, run and sign off UAT. It is written for business owners, project leads and process experts.
What user acceptance testing proves
User acceptance testing, often called UAT, asks one plain question. Can staff use this software to do their work?
The ISTQB testing glossary defines acceptance testing around user needs, business processes and agreed acceptance criteria. The people who accept the system should be able to decide whether it is fit for use.
UAT sits near the end of a build, but its rules should be set much earlier. Our guide to writing a software specification shows how to record those pass rules before the build starts.
Where UAT sits in software development
Quality assurance and developer tests check the application throughout the development cycle. UAT is a later stage. It uses business requirements and realistic test scenarios to judge whether the finished software is ready for production.
Agile teams may run UAT for each release rather than once at the end. The goal stays the same. Business users perform the work, record issues and give clear feedback against the agreed result.
For a bespoke CRM system, the result might be a sales handover with no lost notes. For a bespoke ERP system, it might be a stock receipt that updates purchasing and accounts. Customer portal software may need to accept a document, scan it and show the right status to staff.
Verification and validation are different jobs
The words sound alike, but they answer different questions. Verification checks the specification. Validation checks the business need.
The UK Government's Teal Book guidance on verification and validation was updated on 1 July 2026. It states that user acceptance tests validate whether the user need has been met. The update also says validation decisions should use acceptance criteria set in advance.
| Check | Verification | Validation and UAT |
|---|---|---|
| Main question | Was it built to the agreed design? | Does it meet the real user need? |
| Typical owner | Developers and technical testers | Business users and the product owner |
| Typical evidence | Automated tests, logs and technical results | Completed business journeys and user evidence |
| Example | The refund API returns the right response code. | The refund updates the order, stock, tax record and customer. |
| Decision | The feature matches its specification. | The business can accept the feature for use. |
You need both. UAT should not replace code tests. Users should not spend time finding broken buttons that the build team could find first.
Choose testers who know the work
The best UAT testers are not always managers. Choose people who do the task often and know its awkward cases. They know which fields arrive late, which customers need an exception and which handover tends to fail.
An order journey may involve sales, warehouse staff, accounts and customer service.
- Name one business owner who can make the acceptance decision.
- Choose process experts for each main user role.
- Give one person control of the test log and evidence.
- Keep developers ready to explain, investigate and fix.
- Separate the tester from the person who built the feature.
Turn business needs into pass rules
An acceptance criterion is a result the system must produce. The GOV.UK Service Manual describes acceptance criteria as outcomes used to confirm that a service has met a user need.
Good criteria are clear enough to pass or fail. "The order screen is easy to use" is too loose. "A sales user can add a delivery address without seeing finance-only fields" can be checked.
Write criteria around outcomes
- State who performs the task.
- Describe the starting business state.
- Name the action they must complete.
- Set the result in every affected system.
- Include access, audit and error rules.
- Define what evidence proves the result.
Cover normal work first. Then add edge cases. Useful edge cases include duplicate records, missing data, expired permissions and an integration that does not answer.
Prepare a safe and useful test environment
A good test script can fail in a poor test setup. UAT needs the right roles, data, links and system settings. It should feel like live use without exposing live personal data.
Use made-up or masked records. Include the same data shapes that cause trouble in real work. Test long company names, blank optional fields, duplicate references and unusual order states. Never copy a live database into a test system without a lawful need and proper controls.
Check every link the workflow needs. Some outside services have no safe test mode. Use a safe stand-in and record that limit.
- Create each user role with realistic access.
- Load known test records with expected results.
- Confirm email, payment and document services are in test mode.
- Set a known software version for the whole test run.
- Agree how the environment will be reset.
- Keep live customer and staff data out.
Write test cases as real business tasks
A test case should read like a piece of work, not a tour of the screen. "Click Save" has no business meaning. "Refund one returned item while keeping the rest of the order fulfilled" does.
Sample UAT test case
| Test ID | UAT-ORD-014 |
|---|---|
| Business task | Refund one returned item from a completed two-item order. |
| Tester | Customer service adviser with refund permission. |
| Starting state | A paid order contains two stock items. Both were sent. One has come back into the warehouse. |
| Actions | Find the order. Select one item. Choose the return reason. Confirm the line refund. |
| Expected result | The order stays partly fulfilled. One item returns to available stock. The payment record shows the amount paid for that line. The tax record shows matching net and VAT values. The customer gets one clear email. The audit log names the adviser. |
| Evidence | Order reference, refund reference, stock movement, tax entry, email copy and audit event. |
| Pass rule | Every expected result is present and no unrelated order value changes. |
This case crosses orders, stock, payments, tax, email and the audit log. That is the point. A workflow often crosses several parts of bespoke software and more than one outside service.
Run UAT with a clear record
Brief testers before the formal run. Explain the goal, data and evidence. Show them how to log a fault, but do not coach them through each task. If the process needs constant help, that is useful evidence.
Record the planned result before the tester starts. For each case, keep the status, tester, software version, date, evidence and defect link. Use Pass, Fail, Blocked or Not Run. Avoid "mostly passed" because it hides the decision.
A blocked test is not a pass. It means the team could not reach a result. Fix the block or make the launch risk clear.
Rate defects by business impact
Severity describes the harm a defect can cause. Priority says when the team plans to fix it. Keep the two separate. A spelling error on a legal notice may be simple to fix but still need urgent action.
| Severity | Business impact | Realistic example | Normal release position |
|---|---|---|---|
| Blocker | A critical journey cannot finish or data is unsafe. | Dispatch staff cannot produce any carrier labels. | No-go until fixed and passed. |
| High | A main task gives a wrong result or lacks a safe route around it. | A partial refund posts the full order value to accounts. | No-go unless a named owner accepts a tightly controlled exception. |
| Medium | Work can continue, but a known step is slow or awkward. | A planner must refresh before a newly assigned job appears. | May launch with an owner, action and support note. |
| Low | The task works and the fault has little business effect. | A table heading wraps badly on a small laptop. | Can be accepted into planned follow-up work. |
Use the matrix as a starting point. Set the final definitions before UAT. A payroll fault and a catalogue fault may need different thresholds.
Follow a test timeline with decision gates
UAT should have a set order, even when the launch is phased. The Teal Book's transition into use guidance covers this point. Check the full system, or one live part, in a controlled test setup. Use the agreed pass rules.
- Set the gate. Agree the business journeys, criteria, severity rules and sign-off owner.
- Prepare the ground. Create users, test data, integrations and a fixed release version.
- Run a dry check. Prove that scripts and data work before business testers arrive.
- Run formal UAT. Test each journey and save the evidence.
- Triage faults. Rate impact, assign ownership and decide what blocks release.
- Retest changes. Repeat failed cases and nearby journeys that the fix may affect.
- Make the decision. Compare the final position with the gate set at the start.
- Check early live use. Watch the first real journeys and follow the agreed fallback plan if needed.
Make a go or no-go decision
Sign-off is a choice backed by test proof. It does not promise that the software has no faults. It confirms that known risks sit within the level the firm agreed to accept.
| Decision area | Go | Conditional go | No-go |
|---|---|---|---|
| Critical journeys | All pass. | A non-critical branch has a safe, tested route around it. | A core task fails or is blocked. |
| Open defects | No blockers or high defects. | Medium or low defects have named owners. | A blocker remains or a high defect lacks safe control. |
| Data | Totals and key records match. | A small known gap can be checked by hand. | Data is missing, duplicated or cannot be traced. |
| Operations | Users, support and access are ready. | Extra support covers a limited issue. | Staff cannot run or support the process. |
| Fallback | The fallback has an owner and has been checked. | The fallback is limited but suits the release scope. | There is no safe way back if launch fails. |
Use a clear sign-off checklist
The sign-off record should be short enough to read and firm enough to audit. Link to detail instead of pasting every screenshot into one document.
- Every planned test has a final status.
- All critical business journeys have passed.
- Failed and blocked tests link to named defects.
- Each accepted defect has a business owner.
- Data checks cover totals, samples and audit history.
- User access and role limits have been tested.
- Training and support information matches the final release.
- The fallback plan has an owner and a trigger.
- The exact accepted software version is recorded.
- The decision names who approved it and when.
If an API integration sits inside a critical journey, keep evidence from both sides. A sent request is not proof that the receiving system used it correctly.
Avoid the UAT traps that weaken sign-off
Testing only the happy path
Normal cases prove the route works. Exceptions prove the business can cope when work gets messy. Test cancellations, duplicates, failed payments and changed permissions where they matter.
Using developers as the only testers
Developers know how the feature was meant to work. Users know how the work does happen. Both views matter, but they are not the same.
Writing steps without expected results
A list of clicks cannot support a fair pass. State the result you expect and the proof needed.
Fixing faults during the same test run
A changing release makes test proof hard to trust. Record the version. Apply an agreed set of fixes, then retest on a known build.
Treating sign-off as a ceremony
A name at the end of a file proves little on its own. The useful record links the user need, pass rule, test, result, fault and final call.
Plan UAT when the work is first defined
Strong UAT starts before the test site exists. Agree outcomes when the work is first mapped. Keep them linked to needs as the build changes. Name the users who will test them. Set aside safe data and clear staff time.
This approach also makes a bespoke software build easier to control. The team can show which need each feature meets. The business can see what will count as done.
If your current project has vague acceptance rules, fix that before adding more test scripts. Map the key business journeys first. Then turn each result into a pass rule. Dev Moves can help with that work through a focused software project review.
Source notes
- The Teal Book, Chapter 34: Verification and validation. Last modified 1 July 2026. It links UAT to user needs and says validation decisions should use predefined acceptance criteria.
- The Teal Book, Chapter 36: Transition into use. It covers controlled acceptance of a full solution or a phased operational part.
- Government Functional Standard GovS 002: Project delivery. Its glossary separates verification against a specification from validation against business need.
- ISTQB glossary: acceptance testing. It defines formal acceptance testing around user needs, business processes and acceptance criteria.
- GOV.UK Service Manual: writing user stories. It describes acceptance criteria as outcomes used to check that a user need has been met.
