User Acceptance Testing (UAT): How to Run It Well

Contributor
Mar 16
5 min read

User Acceptance Testing is the phase where actual users (or representatives) verify the system works for their use cases before broad release. Done well, it surfaces real-world issues that internal testing missed. Done badly, it becomes a customer demo where everyone agrees the system is fine and discovers the issues post-launch instead.

This guide is the practical version.

What UAT Is For

UAT exists to answer one question: does the system actually work for the users who'll use it?

Internal tests verify the system meets the specification. UAT verifies the specification meets the users.

The two are different. A system that perfectly implements a wrong spec passes internal tests and fails UAT. That's exactly the kind of issue UAT exists to find.

What UAT Is Not

UAT is not:

A bug-finding phase for issues internal testing should have caught
A demo where users say "looks great"
A sign-off ritual to satisfy contract requirements
Marketing approval

When UAT is treated as any of these, it produces signatures and few useful findings.

Selecting UAT Participants

Real users, or people who genuinely represent them.

Good participants:

People who'll use the feature regularly
People who'd be affected if it's wrong
People with different roles or use cases (varied perspectives)
People comfortable giving honest feedback

Bad participants:

Stakeholders far from the actual use
People who feel obligated to approve
People who lack context to evaluate

Five to ten participants for a typical UAT is workable. More than that and feedback becomes hard to integrate.

Structuring the UAT

Two main approaches.

Scripted UAT: users execute specific scenarios, comparing results against expected outcomes. More structured; easier to interpret; less likely to surface unscripted issues.

Exploratory UAT: users use the system as they would in real work, reporting what they find. More likely to surface real-world issues; harder to interpret.

The best UAT combines both: scripted scenarios for the critical paths, exploratory time for users to wander.

Preparing for UAT

Before participants touch the system:

Environment ready. Stable, with realistic data, accessible
Scenarios documented. Clear scripts for the scripted portion
Success criteria defined. What does "passes UAT" mean specifically?
Issue reporting process clear. Where do they file what they find?
Time committed. Participants have actual time blocked, not "fit it in when you can"

A UAT where participants aren't sure what they're supposed to do produces vague feedback.

During the UAT

Watch what users do. Especially:

Where do they hesitate?
Where do they go off the expected path?
What do they call something that you call something else?
What's confusing?
What's frustrating?

The watching matters as much as the explicit feedback. Users will say "this is fine" while struggling to do basic things. The struggle is the feedback.

For remote UAT, screen sharing helps. Recordings (with permission) help more — you can rewatch the moments of confusion.

What to Capture

Feedback from UAT should be specific:

What scenario produced the issue
What the user expected
What actually happened
How important is this (blocking, annoying, cosmetic)
Whether the user could work around it

"It's confusing" is not actionable. "When I clicked 'Save,' I expected to stay on the page; instead I was redirected to a list view" is.

Distinguishing Bugs From Design Issues

UAT surfaces two kinds of feedback:

Bugs: the system isn't doing what was specified. Fix.

Design issues: the system is doing what was specified, but the specification was wrong. Decide whether to change the spec.

Both are valid UAT findings. The team's response is different:

Bugs → fix before launch
Design issues → triage; some fix, some defer, some accept

Treat both seriously. UAT-discovered design issues are particularly valuable because they're caught before customers experience them.

Sign-Off

The deliverable of UAT is typically a sign-off — formal acceptance that the system is ready for release.

What sign-off should mean:

The participants have actually tested
Issues found have been addressed or explicitly accepted as out of scope
The participants believe the system serves the use case

What sign-off shouldn't mean:

Participants haven't really used the system but signed anyway
All issues are dismissed
The team is locked into a final version

A meaningful sign-off documents acceptance with a list of known issues being accepted. An empty sign-off is a signature.

When UAT Goes Wrong

Participants don't engage. They click a few things and approve. Solution: give them specific scenarios and observe them executing.

Sign-off pressure. Team is too far in to make changes. UAT becomes ceremony. Solution: budget time after UAT for fixes.

Wrong participants. Stakeholders far from the work say it's fine; real users find issues post-launch. Solution: pick participants closer to actual use.

Internal testing wasn't done. UAT discovers basic bugs that should have been caught earlier. Solution: don't skip internal testing — UAT is for different kinds of issues.

No follow-up. UAT findings get logged and forgotten. Solution: triage and assign all UAT findings; track to closure.

UAT vs. Beta

UAT and beta testing have similar shapes but different purposes.

UAT: specific users, specific scenarios, formal sign-off, before launch.
Beta: broader user base, real-world usage, gathering feedback for iteration, may be ongoing.

A typical sequence: internal testing → UAT → beta → general availability. Each catches different things.

Some teams combine UAT and beta into "controlled rollout" — a small set of real users in production with extra monitoring. This works for products where dedicated UAT is impractical.

Cadence

For most products, UAT happens:

Before major releases
Before launches of new features that change workflows
Before changes to critical paths
As contracted (some enterprise contracts specify UAT)

For continuously-delivered products, UAT can be reframed as ongoing beta with selected customers. The principle (real users verify before broad release) remains.

A Working Process

Step-by-step for a typical UAT:

Plan (week T-2): define scenarios, success criteria, participants, schedule.
Prepare (week T-1): stabilize environment, validate scripts, brief participants.
Execute (week T): participants test; team observes; issues captured.
Triage (week T): issues categorized as bugs or design issues, prioritized.
Fix (week T+1): critical issues addressed.
Verify (week T+1): participants re-test fixes.
Sign-off (week T+2): formal acceptance documented.
Launch (week T+2 or T+3): release.

Compress for smaller releases, expand for larger ones.

Documenting UAT

The UAT deliverables:

Test plan: scenarios, criteria, participants
Test results: what was executed, what passed, what failed
Issue list: findings with severity and status
Sign-off: documented acceptance with known issues

For most products, this is a few pages. For regulated products (medical, financial), more formal documentation may be required.

Key Takeaway

User Acceptance Testing verifies that the system works for its users, not just that it meets the spec. Pick real users, combine scripted and exploratory testing, observe in addition to asking for feedback. Capture specific findings, distinguish bugs from design issues, and budget time after UAT for fixes. The sign-off should be a meaningful acceptance, not a ceremony. UAT done well catches the issues that would otherwise become customer reports post-launch.

ShiftQuality