Planning3 min read
User Acceptance Testing for Custom Software: A Business Checklist
Plan user acceptance testing with real roles, representative data, clear pass criteria, and a release decision. Includes an example test record.
Written byNeil BusqueProduct builder · Updated
Field notes, minus the motivational fog.
Workflow examples are illustrative. Research and drafting may be AI-assisted; technical references checked September 4, 2026.
User acceptance testing, or UAT, checks whether the people who will use a system can complete the agreed business work with it. It complements developer testing by examining the real workflow, roles, data, and exceptions. UAT is not simply a presentation in which the builder clicks through the easiest path. The demo customer who always supplies perfect information is unlikely to be your only customer.
Define acceptance before the final review
Choose the core workflow and write the result that would make it ready for use. Identify which people must test it, what data they need, and which exceptions belong in the first release. Microsoft’s implementation guidance distinguishes user acceptance testing from other test types; a business review does not replace technical checks for security, performance, or integrations. Microsoft Learn reference
Example: a coordinator launches a new client project
For an illustrative onboarding app, the coordinator starts with an approved client record, collects the required details, assigns an owner, and marks the project ready. Test a complete submission and one with a missing required file. The incomplete case should remain visible and blocked at the correct step, with a clear instruction rather than a generic error.
| Field | Example |
|---|---|
| Scenario | Prepare a client project with one required file missing. |
| Role | Project coordinator with normal permissions. |
| Starting data | Test client, approved scope, incomplete intake. |
| Expected result | Project remains awaiting the file; owner and next action are visible. |
| Actual result | Recorded by the tester after running the steps. |
| Release decision | Pass, fix and retest, or an explicitly accepted limitation. |
Run a useful acceptance session
- 01
Use the actual roles
Give testers accounts with the permissions they will have after launch. An administrator account can hide access problems.
- 02
Let users perform the tasks
Ask people to complete outcomes without continuous coaching. Record where instructions, status, or navigation are unclear.
- 03
Check the connected result
Verify the saved record, notification, or downstream task. A success message on screen is only part of the evidence.
- 04
Retest the repair
When an issue is fixed, rerun the affected case and any closely related flow. Do not close it based only on the builder’s description.
Include conditions that reveal hidden gaps
- Required information is missing or invalid.
- A user tries to view another client’s record.
- An integration is unavailable or responds slowly.
- The user submits the same action twice.
- A task is completed on the phone or tablet used in daily work.
Classify findings by their effect on the agreed workflow. A blocked core task, a wrong record update, and an unreadable control can stop launch. Minor cosmetic preferences may be documented for later if the decision-maker accepts them. Keep that distinction visible so a growing list of new ideas does not obscure unresolved defects.
Make the final release decision explicit
Summarize the scenarios tested, unresolved issues, owners, and any agreed workarounds. Identify who authorizes launch and who supports users afterward. UAT should end with evidence that the agreed workflow works, or a clear list of what must change before it can. It should not depend on everyone remembering what they saw in a meeting.
Frequently asked questions
Who should do UAT?
The people responsible for the real workflow, supported by a decision-maker who can accept or reject the release. The builder can help prepare data and investigate failures.
How long should UAT take?
It depends on workflow breadth, roles, integrations, and risk. Plan enough time to test the agreed scenarios, fix blocking issues, and retest them before launch.