User Acceptance Testing (UAT): Process, Checklist and Real Examples

A team once delivers an expense system that passes every technical test. On the first day, the finance team discovers that it cannot handle multi-currency claims, which make up a large share of their work. Nothing was “broken”, but it was not usable. User acceptance testing exists to catch exactly that kind of gap before launch.

This guide covers how UAT differs from other testing, how to run it step by step, and how to decide when you are ready to release. The scenario above and the examples below are illustrative, and the process should be scaled to suit your project.

What is UAT?

UAT is usually the final testing phase before release, where the intended users confirm that the software can do their job in realistic conditions. It is also called end-user testing or acceptance testing. It comes after development and system testing, when the product is expected to be stable.

Its purpose is not to find every bug. By this stage, most of those should already be gone. The aim is validation: did we build the right thing? Testers verify that the product matches the specification. UAT validates that the specification, and the product, actually meet the need.

UAT vs QA testing

UAT does not replace other testing. If users keep hitting basic bugs, the build was not ready, and you are wasting their limited time. Those issues belong in earlier test levels and regression testing.

Who runs UAT?

Choose testers who really do the work today. An experienced claims handler will spot problems that a manager or a proxy never would. Include a range of experience, because a new employee often reveals confusing steps that an expert works around without noticing. And make sure that their managers free up time for this, as UAT cannot succeed on top of a full workload.

Types of UAT

The seven-step UAT process

1. Define scope and goals

Decide what is being accepted, what is out of scope, and what business outcomes matter. For example: “Finance staff can submit, approve and pay an expense claim, in any supported currency.”

2. Agree on acceptance criteria

Write down in plain language what success looks like, ideally at the start of the project rather than the week before launch. Vague criteria lead to arguments later on.

3. Choose and brief testers

Select real users, explain the purpose, show them how to record feedback, and make clear that they are testing the software rather than being tested themselves. Many people worry about getting something wrong.

4. Prepare the environment and data

The UAT environment should resemble production as closely as is practical. Use realistic data, set up the correct user roles, and check integrations such as email. If you copy production data, mask personal information first. Run a quick smoke test, so that testers do not arrive to find a broken build.

5. Write scenarios

Base these on real workflows rather than individual buttons. They should read like the job, not like the software. Our guide to test case vs test scenario explains how much detail you need.

6. Run the tests and collect feedback

Run sessions with someone available to help. Collect issues in one place, with screenshots. Leave some time for free exploration too, since people try things that scripts never anticipate. Exploratory testing offers useful techniques for this.

7. Fix, retest and sign off

Triage the feedback, fix what matters, and have the same users confirm the fixes. Then record a formal decision.

A UAT test case

A UAT test case should be easy for someone non-technical to follow. Here is an example for an expense system:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Note that it describes a real task, not technical details, and that it leaves room for comments. Those comments frequently turn out to be the most valuable part, such as “this works, but I would never find that button”.

Entry and exit criteria

These fit into the wider software testing life cycle. Set the numbers with your stakeholders in advance. “We will decide when it feels right” tends to lead to a rushed yes, driven by the deadline.

Handling feedback

UAT feedback is a mixture of things, and not all of it is a bug. Sort it into categories:

Use clear rules for what blocks a release, as described in severity vs priority. And respond to every item, including the ones you decline. People stop giving feedback if it seems to disappear. Our guide on how to write a bug report may help testers describe issues clearly.

UAT checklist

Before UAT

• Scope and acceptance criteria are agreed in writing
• System and regression testing are finished
• Testers are chosen, briefed and given time
• Environment, accounts and realistic data are ready
• Personal data in copies has been masked
• Scenarios are reviewed by the business
• One place to record issues is set up
• Sign-off owner is named

During UAT

• A support contact is available
• Issues are triaged every day
• Progress is shared with stakeholders
• Fixes are deployed and retested in a controlled way

After UAT

• Exit criteria have been checked
• Known issues are documented, with owners
• Formal sign-off is recorded
• Training and release notes are updated
• A short retrospective has been held

UAT in Agile teams

Traditional UAT comes as one large phase at the end, where a surprise is expensive. Agile teams shorten that loop. Product owners review each story against its acceptance criteria during the sprint, and users see working software at sprint reviews. Many teams still run a focused UAT before a major release, particularly where several features combine into one workflow.

With frequent releases, techniques such as feature flags and canary deployments let real users try new work gradually. Note that these complement acceptance testing, but they do not automatically replace it, especially in regulated industries that need a formal record.

Common mistakes

• Treating it as a formality. A sign-off with no real use protects nobody.
• Using the wrong testers. Developers and QA have too much knowledge of the system to represent users.
• Starting with an unstable build. Testers lose trust and interest quickly.
• Leaving it until the last minute. There is then no time to fix what you learn.
• Using unrealistic data. Test data rarely has the messy cases that real work does.
• Letting scope grow. Treat new ideas as change requests, unless they are true blockers.

Final thoughts

UAT is your last chance to learn, before release, whether the software really helps the people who will use it. Plan it from the start of a project, recruit real users, and agree on what success looks like. For your next release, try one simple change: sit with one user during a real scenario, and say nothing while they work.

Frequently asked questions

Keep learning