UAT Software Testing: Process, Checklist and Best Practices

UAT is the last chance to find out that the software works perfectly and still does not do the job. Everything before it checks the system against what someone wrote down. UAT checks it against what people actually do on a Tuesday afternoon with messy data and a queue of customers waiting. This guide covers what UAT is, who runs it, the process step by step, the entry and exit criteria, a checklist you can lift directly, and the failure modes that turn a real gate into a signature ceremony.

• UAT validates fit, not function. Functional bugs at this stage mean system testing did not finish.
• Real users run it. If QA executes the scripts, it is system testing with a different name.
• Production-like environment and realistic data are non-negotiable — clean synthetic data hides the defects real data triggers.
• The fix-and-retest turnaround decides the schedule, not the length of the window.
• Sign-off must be able to return no. If it cannot, the gate is theatre.

What is UAT in software testing?

User acceptance testing is formal testing in which real business users execute their own workflows against a near-final build to determine whether the system is fit to go live. It is the most common form of acceptance testing, and it sits at the very end of the test levels — after unit, integration and system testing have all passed.

The distinction that defines it is validation versus verification. Verification asks whether the system matches its specification; that is what QA testing does. Validation asks whether the system meets the real need. A build can satisfy every documented requirement and still fail UAT, because the requirement itself was wrong, incomplete, or described a process nobody actually follows.

A concrete example: a claims screen implements every documented rule correctly. It passes system testing cleanly. In UAT, an adjuster who has done the job for eleven years opens it and finds that real claims arrive in batches of thirty, that half of them need a note attached before approval, and that the screen handles one claim at a time with no notes field. Nothing is broken. Everything is wrong. Only someone who does the work could have told you.

UAT is also a decision, not just an activity. Its output is not a defect list — it is an accept, accept-with- conditions, or reject, made by someone with the authority to make it. If your UAT produces bug reports but no formal decision, you are running late system testing. UAT is one of several acceptance types; the broader picture, including business, contract, regulatory, operational, alpha and beta acceptance, is covered in the acceptance testing pillar.

Why does UAT exist?

UAT exists because requirements are an imperfect translation of reality, and no amount of testing against a specification can detect an error in the specification itself.

Every project performs the same lossy chain: a business process lives in people's heads and habits, someone interviews them and writes requirements, an analyst refines them into stories, a developer interprets those stories into code, and a tester verifies the code against the written version. Each step loses something. Unit, integration and system testing all verify against the written artefacts — so they can only catch errors introduced after the writing. If the loss happened during the interview, every test passes and the software is still wrong.

UAT is the only stage that closes the loop back to the source. It puts the software in front of the people whose heads the process actually lives in. That is why it finds a distinctive class of problem:

• Missing steps nobody mentioned because they are too obvious to say out loud.
• Volume and shape mismatches — the real work arrives in batches, the design assumed one at a time.
• Exception paths that are rare in the spec and routine in practice.
• Cross-system reality — the process leaves your application halfway through and comes back.
• Usability at speed — workable in a demo, unusable at forty repetitions an hour.

None of those are defects in the ordinary sense. Nothing is broken. They are fit failures, and finding them before go-live rather than after is the entire return on the exercise. For where this sits in the wider prevention-versus-detection picture, see QA vs QC.

Who performs UAT?

Real business users perform UAT — the people who will use the system to do their jobs. Not QA, not developers, not business analysts representing users, and not managers who supervise the process without performing it.

This rule is broken constantly, and always for reasonable-sounding reasons: users are busy, the date is close, testers are available and know the scripts. So QA executes the UAT scenarios on the users' behalf and everyone signs. The result looks identical on paper and is worthless in practice.

Here is why the substitution destroys the value. A tester executes what is written — that is the discipline, and it is exactly right for system testing. A real user deviates. They try the thing they actually do, in the order they actually do it, with the data they actually have, and they stop halfway through to say "we would never do it like this". The deviation is the mechanism. Remove the user and the mechanism is gone, no matter how faithfully the scripts get executed.

Choosing participants well matters more than the number of them:

• Cover every role that touches the process — approver, processor, supervisor, support, finance.
• Mix experience levels. Veterans find process gaps; new starters find usability gaps. You need both.
• Get people who do the job, not people who manage people who do the job.
• Release them from their day job. A user squeezing UAT between meetings gives you the happy path and goes home.
• Include the awkward customer. The person with the strongest opinions finds the most, and you would rather hear it now.

QA's role around UAT is substantial, but it sits either side of execution rather than in the middle of it:

• Preparing the environment, data and access before day one.
• Writing scenarios in business language rather than test-case syntax.
• Briefing participants on how to record findings.
• Sitting in sessions to capture defects properly — users report symptoms, not reproduction steps.
• Triaging findings into defects, change requests, training gaps and works-as-designed.
• Driving the fix-and-retest loop against the clock.

What is the UAT process step by step?

Run UAT as a planned phase with named participants, prepared scenarios and an agreed fix loop — not as an open invitation to click around staging and see what happens.

1. Plan. Define scope, participants, roles, timeline, environment and — critically — who holds the authority to accept. Confirm that person exists and knows it.
2. Design scenarios. Derive end-to-end business scenarios from real processes and acceptance criteria. Written in the user's language, following the workflow across systems where the real process does.
3. Prepare the environment and data. Production-like configuration, live-shaped data, real integrations, correct role permissions. This is the step that most often runs late and most often sinks the phase.
4. Verify entry criteria. Do not start on an unstable build. A broken day one costs more than a delayed start, because participants disengage and do not come back.
5. Brief participants. What to test, how to record it, what counts as a defect versus a change request, how long it takes, and who to ask when stuck.
6. Execute in scheduled sessions. Book the time, have QA in the room, and let users work their own way through the scenarios. Capture findings live with steps, data, screenshots and expected-versus-actual.
7. Triage daily. Sort every finding into defect, change request, training gap or works-as-designed. Agree severity with the business, not on their behalf.
8. Fix and retest. Defects move through the bug life cycle to verification, plus a regression check that the fix broke nothing adjacent.
9. Verify exit criteria and sign off. A formal, recorded decision with evidence: accept, accept with conditions, or reject.
10. Hand over known limitations. Deferred defects, workarounds and gaps go to support and operations before go-live, not after the first ticket arrives.

Step 8 is where schedules actually die. If a defect found on Tuesday reaches a verifiable build the following week, UAT stalls, the window overruns and users lose faith that reporting anything changes something. Agree the fix-to-deployed-build turnaround before day one — daily is workable, weekly is not — and staff for it. That is a pipeline question as much as a planning one; if functional testing and the build process cannot produce a verified build daily, no UAT plan survives contact.

What are UAT entry and exit criteria?

Entry criteria define when UAT is allowed to start; exit criteria define when it is allowed to finish. They exist to prevent the two most common failures: starting on a build that is not ready, and stopping because the date arrived rather than because the system is acceptable.

UAT entry criteria

• System and integration testing complete, with results reviewed and signed off.
• No open critical or high-severity defects in the UAT scope.
• Acceptance criteria documented and agreed by the business before the build.
• Production-like environment available, stable and dedicated to UAT.
• Realistic test data loaded, with correct permissions for every role.
• UAT scenarios written, reviewed and understood by participants.
• Named participants confirmed, briefed, and released from day-job commitments.
• Defect capture, triage and fix-turnaround process agreed and communicated.
• The accepting authority identified by name.

UAT exit criteria

• All planned UAT scenarios executed.
• All critical and high-severity defects fixed, retested and verified.
• Every remaining defect explicitly accepted, deferred with a named owner, or marked blocking.
• Acceptance criteria demonstrably met, with recorded evidence.
• Formal sign-off from the accepting authority.
• Known limitations and workarounds documented and handed to support and operations.

The exit criterion teams skip is the third one — explicitly deciding the fate of every unresolved defect. "We will fix it after launch" is a legitimate decision when it is actually a decision with an owner and a date. It becomes a problem when it is an unspoken assumption that evaporates the moment the release ships and everyone moves to the next thing.

UAT checklist

A working UAT checklist, grouped by phase. Use it as a gate, not a formality — each item is something that has sunk a real UAT phase when skipped.

Before UAT starts

• Scope agreed and written down: what is in, what is explicitly out.
• Accepting authority named, and aware they hold the decision.
• Participants identified per role, confirmed, and released from day-job work for the window.
• Timeline agreed, including the fix-and-retest turnaround, not just the end date.
• End-to-end scenarios written in business language and reviewed by a real user.
• Acceptance criteria traceable to scenarios — every criterion covered by at least one.
• Production-like environment provisioned, stable and not shared with other testing.
• Realistic data loaded: real volumes, real shapes, real edge cases, correctly masked.
• Integrations pointed at live-like endpoints, not stubs.
• Access and permissions verified for every participant, per role, before day one.
• Defect tracker configured with a UAT-specific field, severity scale and workflow.
• Participants briefed on how to record findings and what counts as a defect.
• Entry criteria formally verified — not waived to protect a date.

During UAT

• Sessions scheduled and attended, with QA present to capture defects properly.
• Every finding logged with steps, data used, role, screenshot and expected versus actual.
• Daily triage: defect, change request, training gap or works-as-designed.
• Severity agreed with the business rather than assigned for them.
• Fixes deployed to the UAT environment on the agreed cadence.
• Retest confirmed by the original reporter, not by the developer who fixed it.
• Regression check run around each fix.
• Scenario coverage tracked daily against plan — visibly, where participants can see it.
• Blockers escalated the same day, not at the weekly status meeting.

Before sign-off

• All planned scenarios executed and results recorded.
• Critical and high defects closed and verified.
• Every open defect has an explicit decision and an owner.
• Evidence pack complete: what was tested, by whom, when, with what outcome.
• Known limitations documented and handed to support and operations.
• Sign-off obtained from the named authority, recorded, with conditions written down if any.
• Rollback plan confirmed in case go-live goes badly.

How do you write UAT test cases?

Write UAT scenarios as end-to-end business processes in the user's own language — not as screen-by-screen test steps. This is the single biggest difference between UAT scenarios and system test cases, and getting it wrong quietly converts UAT into system testing.

A system test case reads: navigate to Refunds, enter 50 in the Amount field, click Submit, verify the confirmation message appears. A UAT scenario reads: a customer calls to dispute a $50 charge on an order from last month; process the refund and confirm it reaches the customer and appears in today's settlement.

The difference is that the second one requires the user to work out how. That is deliberate. If they cannot work it out, you have found something — and a step-by-step script would have hidden it by telling them exactly where to click.

Practical rules:

• Start from the real process, not the requirements document. Ask a user to describe their day.
• Follow the workflow end to end, including the parts that leave your system and come back.
• Describe the goal and the context, not the clicks. Give a starting situation and a desired outcome.
• Use real business vocabulary. If users say "chargeback", the scenario says chargeback, not "negative transaction event".
• Include the exceptions users actually hit — the rejected payment, the duplicate record, the customer who changes their mind halfway.
• Cover each role separately. An approver's scenario is not a processor's scenario.
• Make the expected outcome observable in business terms: "the refund appears on the customer's statement", not "the API returns 200".
• Leave room for deviation. Add an explicit "do it the way you normally would" instruction and let them.

Traceability still matters: every acceptance criterion should be covered by at least one scenario, so you can demonstrate at sign-off that nothing agreed was left untested. Keep the mapping in a simple matrix — criteria down one side, scenarios across the top.

What environment and data does UAT need?

UAT needs a production-like environment with realistic data and live-like integrations. Anything less validates a system that does not exist, and the gap is where the post-launch incidents come from.

Environment requirements. Dedicated to UAT, not shared with system testing or development — a build changing under a user mid-session destroys trust and wastes the slot. Configured like production: same versions, same settings, same feature flags. Integrations connected to live-like endpoints rather than stubs; a stub always returns the tidy response, and production never does. Realistic performance characteristics too, because a screen that is workable at 200ms is unusable at four seconds, forty times an hour.

Data requirements. This is where UAT most often falls over, because clean synthetic data hides exactly the defects real data triggers:

• Real volumes. A customer with 900 transactions behaves differently from one with three.
• Real shapes. The 40-character surname, the address with no postcode, the legacy record with a null field that "cannot happen".
• Real history. Records created before the last three schema migrations, which is most of them.
• Real edge cases. The account in dispute, the partially refunded order, the customer who exists twice.
• Correctly masked. If it is derived from production, it must be anonymised properly — UAT is a data-protection surface like any other.
• Refreshable. Users consume test data. A one-shot dataset means day three has nothing left to test with.

Budget for data properly. "We will sort the data out" is the sentence that precedes a week of UAT delay more often than any other, because building representative, masked, refreshable data is a real engineering task and it is invariably scheduled as an afterthought.

How does UAT sign-off work?

UAT sign-off is a formal, recorded decision by a named authority that the system is acceptable — with three valid outcomes: accept, accept with conditions, or reject.

Accept-with-conditions is the one that gets used most and understood least. It means: we are going live, and these specific known defects are being carried, each with an owner and a date, and support and operations know about them. That is a legitimate and often correct business call. It becomes dangerous when the conditions are verbal, ownerless and forgotten by the following Monday.

What sign-off must record:

• Who accepted — a named person with the authority to do so.
• What was tested — scenarios executed, by whom, with what results.
• What was not tested — the scope gaps, stated plainly.
• Open defects and their disposition — accepted, deferred with owner and date, or waived.
• Conditions attached to a conditional acceptance, written down.
• Known limitations handed to support and operations before go-live.

The honest test of whether your sign-off is real: ask what would happen if it returned "reject" two days before go-live. If the truthful answer is "we would ship anyway", you do not have a gate — you have a ceremony, and it is worth knowing that before spending six weeks of business users' time on it.

UAT vs SIT vs QA testing: what is the difference?

SIT verifies that systems talk to each other correctly, QA testing verifies the system matches its specification, and UAT validates that the system works for the business. Different questions, different people, different environments — and they are not interchangeable.

Dimension	QA / system testing	SIT (system integration testing)	UAT
Question	Does it work as specified?	Do the systems work together?	Does it work for the business?
Type	Verification	Verification	Validation
Run by	Testers / SDETs	Testers, integration engineers	Real business users
Tested against	System specification	Interface contracts, data flows	Real business processes
Environment	Test environment	Integrated test environment	Production-like
Data	Controlled test data	Cross-system test data	Realistic, production-shaped
Finds	Functional defects	Interface, mapping, data-flow defects	Fit, workflow and usability gaps
Output	Defect reports	Defect reports	An accept / reject decision
Runs	After integration testing	After component testing	Last, before go-live

The ordering is load-bearing. UAT assumes SIT and QA testing are finished. If users are reporting broken buttons and mapping errors, the earlier levels did not do their job and UAT has been turned into a safety net for upstream failure — which it is terrible at, because business users are not trained to find functional defects and their time is the most expensive in the building. For the full taxonomy of levels and types, see types of software testing.

Why does UAT fail?

UAT fails for organisational reasons far more often than technical ones. The patterns repeat across every industry:

• It becomes a rubber stamp. The date is immovable, sign-off is scheduled, and the only acceptable answer is yes.
• The wrong people test. QA runs the scripts because users are unavailable, and the deviation that finds real problems never happens.
• It starts on an unready build. Entry criteria get waived to protect a date; day one is spent on broken basics and the room never re-engages.
• The environment is not production-like. Stubs and toy data validate a system that will not exist in production.
• It absorbs the project's delay. Development overruns, UAT gets squeezed, and the last gate before the customer gets the least attention.
• The fix loop is too slow. Defects raised in week one appear in a build in week three; participants stop reporting because nothing changes.
• Users are not released from their day jobs. Squeezed between meetings, they run the happy path and go home.
• Findings vanish. Captured in notebooks and hallway conversations, triaged by nobody.
• Scope creep in disguise. Every "this is wrong" is treated as a defect, and UAT turns into an unfunded second requirements phase.

That last one deserves attention, because it is the failure that damages relationships rather than schedules. A large share of what users raise in UAT is not a defect — it is a change request, a training gap, or a correctly built requirement someone now disagrees with. Sorting those honestly, in the room, while everyone remembers the context, is what keeps UAT from collapsing into a renegotiation. Doing it afterwards by email never works.

What tools support UAT?

UAT tooling is deliberately lightweight — the value is in the people, and heavy tooling reliably reduces participation. What you actually need falls into four categories.

• Defect tracking — Jira, Azure DevOps or whatever the team already uses. Add a UAT-specific field or board rather than a separate system nobody will log into.
• Test management — Xray, Zephyr, TestRail or a spreadsheet. For UAT specifically, a well-structured sheet often beats a test-management tool, because business users will not learn one for a three-week engagement.
• Session capture — screen recording and screenshot tools so users can show rather than describe. This single addition improves defect quality more than any process change, because users report symptoms and recordings supply the reproduction steps.
• Feedback capture — a simple form or in-app widget for findings that are not defects: friction, confusion, "why does it do that". These are frequently the most valuable output and the most often lost.

The tooling rule for UAT: whatever you choose, a business user must be able to use it in under two minutes with no training. Every extra step between noticing a problem and recording it loses findings. A perfectly configured test-management suite that users find intimidating produces less signal than a shared sheet and a screenshot folder.

Where automation fits: the acceptance criteria underpinning UAT can and should be automated in the pipeline via BDD-style tests, so they stay verified on every commit. That does not replace UAT — automated checks verify the criteria you knew to write, while UAT finds the ones nobody thought of — but it does mean UAT starts from a build where the known requirements already hold. See the test automation guide for how to build that layer.

How Appsierra helps

Most UAT phases that go wrong were lost before day one: system testing was not genuinely finished, the environment was not production-like, the data was synthetic, or the pipeline could not turn a fix into a verifiable build within a day. Those are all upstream problems, and they surface as "UAT overran" in the status report. Appsierra's pods tend to spend their first weeks on exactly that upstream work — closing out the system-testing layer so UAT is not a bug hunt, and building production-shaped, masked, refreshable data so users test against something real.

We run expert-supervised pods rather than unmanaged contractors, which matters here more than in most testing work. UAT support is largely facilitation and triage: capturing a defect properly from someone describing a symptom, and sorting "this is wrong" into defect, change request or training gap in the room without turning the session into a scope argument. That is a senior skill, and it is the difference between a UAT that produces a clean decision and one that produces a dispute. Our quality assurance services and functional testing cover the layers that make UAT meaningful, and we are ISO 9001 and ISO 27001 certified and CMMI-aligned — which matters when the UAT evidence pack has to satisfy an auditor rather than a stakeholder.

If you would rather have UAT run for you as a managed engagement — participants coordinated, sessions facilitated, evidence pack delivered — that is covered separately under user acceptance testing services. Otherwise, this guide plus the checklist above is genuinely enough to run it yourself, and the broader acceptance testing pillar covers the other acceptance types you may need alongside it. If you want a second opinion on whether your UAT plan will hold, a free 30-minute call with a senior engineer usually surfaces the gap in the first ten minutes — it is almost always the data or the fix turnaround.

Frequently asked questions