Client review
User acceptance testing
User acceptance testing, or UAT, is the last test before release, where the people who will use the software, or the client who commissioned it, confirm that it does the job they asked for.
ISTQB defines it as a type of acceptance testing performed to determine if intended users accept the system. It runs after QA has finished, on the build about to ship, and it ends in a sign-off.
At a glance
| Stands for | User acceptance testing, usually shortened to UAT |
| ISTQB definition | "A type of acceptance testing performed to determine if intended users accept the system" (ISTQB), where acceptance testing is "a test level that focuses on determining whether to accept the system" (ISTQB) |
| Who runs it | Business users or the client, not the developers; consultants or QA prepare and guide the cycle (Microsoft) |
| When | After functional, process and end-to-end testing, on the latest build, before go-live (Microsoft) |
| Tests against | Real workflows with real data, run by the people who do that work daily (Microsoft) |
| Ends with | A sign-off: the business accepts the solution before it is deployed (Microsoft) |
| Collected with | OverlayQA Client Review and Team Review |
Why it matters
QA checks the build against the specification; UAT checks it against the job. ISTQB separates acceptance testing from the other test levels precisely because its question is different: not "does this work?" but "do we accept this?" (ISTQB). Microsoft's implementation guidance calls UAT the closest test to running live operations, always manual, done by business users on real data, and a prerequisite for go-live, because its purpose is sign-off from the people who will live with the result (Microsoft). For an agency, UAT is the moment the client says yes, so where their comments land, and whether each one points at the page it came from, decides how many rounds that takes.
How do you run user acceptance testing?
- 1. Agree what "accepted" means first. Write pass or fail criteria per workflow before anyone tests, so a result is a verdict rather than an opinion. See UAT acceptance criteria.
- 2. Pick the testers. The people who will do the work daily, trained on the new system before they start; Microsoft names order processors, accountants and shippers for a sales order flow.
- 3. Stage the real thing. The latest build with customer data, migrated data included, in a dedicated test environment (Microsoft).
- 4. Run the real workflows, by role. Each tester covers the processes and variations in scope for their job, end to end, not a checklist of screens.
- 5. Record every finding where it happened. A comment on the page, with a screenshot and what was expected, beats a line in an email thread.
- 6. Fix, re-test and sign off. The final iteration ends with the business accepting the solution before deployment (Microsoft).
UAT vs. QA testing
| QA testing | User acceptance testing | |
|---|---|---|
| Who | Testers and developers | The client or the business users |
| Asks | Does it work as specified? | Does it do the job we need? |
| Tests against | Requirements and designs | Real workflows with real data |
| When | Throughout the build | Last, on the release candidate |
| Ends with | Bugs filed and fixed | A sign-off, or a list of what blocks it |
Common mistakes
- Letting the build team run it. The developers already know the spec. ISTQB puts acceptance in the hands of the intended users.
- Starting without criteria. With no agreed pass or fail, UAT becomes a taste test and the sign-off never comes.
- Testing sample data on an old build. Microsoft asks for the latest version and the customer's own data, migrated data included.
- Treating UAT as bug hunting. Finding defects is QA's job. UAT answers whether the people who asked for the software accept it.
- Collecting feedback in email and chat. "The second page looks wrong" with no URL, screenshot or viewport costs a round trip per comment.
- Untrained testers. Microsoft asks that business users be trained on the solution first, so a finding is about the software and not about unfamiliarity.
Frequently asked questions
What does UAT stand for?
User acceptance testing. ISTQB lists UAT as the abbreviation and defines it as a type of acceptance testing performed to determine if intended users accept the system.
Who performs user acceptance testing?
The intended users: the business users who will work in the system daily, or the client who commissioned it. Microsoft describes consultants preparing and guiding the cycle while business users do the testing, trained on the solution first.
When does UAT happen?
Last. Microsoft places UAT after functional, process and end-to-end testing, on the latest build with real data, and makes it a prerequisite for go-live. It is the final check before deployment, and its sign-off is what allows the release.
What is the difference between UAT and QA testing?
QA tests whether the build works as specified; UAT tests whether the people who asked for it accept it. ISTQB treats acceptance testing as its own test level because the question is whether to accept the system, not whether each requirement passes.
Is UAT manual or automated?
Manual. Microsoft describes UAT as always a manual test, done by business users in a dedicated, integrated test environment, because the point is the judgment of the people who will use the system, not a script.
Sources: ISTQB Glossary, user acceptance testing, ISTQB Glossary, acceptance testing, Microsoft Learn, Testing strategy: types of tests (Dynamics 365 implementation guide).
Last updated October 22, 2026