What Is UAT? User Acceptance Testing, Explained

A stressful release usually isn't caused by the release itself. It's caused by everything that wasn't checked before it. User acceptance testing is the last of those checks, and the one most often rushed.

In my teams, QA is involved during development, not only at the end, and every project has separate environments. This article explains what UAT is, how it differs from QA, and the release-readiness checklist I recommend before anything goes to production.

The short answer

UAT stands for user acceptance testing. It is the final round of testing, where the client or the people who will actually use the software check that it does what they need, before it's released. QA asks "does it work as specified?" UAT asks "is this what we need, and do we accept it?" The outcome of UAT is a decision: accept the release, or send it back.

What is UAT?

The ISTQB glossary defines user acceptance testing as a type of acceptance testing performed to find out whether the intended users accept the system. Acceptance testing itself is the test level that decides whether to accept the system at all.

In practice, that means real users or client representatives work through real tasks, in an environment that looks like production, and confirm the software fits the way they work. They aren't hunting for every bug (that's QA's job). They're checking that the requirements were understood correctly in the first place.

UAT meaning in project management

For a project manager, UAT is the formal handover point. Before UAT, the team owns the work. After a successful UAT, the client has accepted it, and anything new becomes a change request rather than a fix. That's why UAT needs clear acceptance criteria, agreed before development starts, and a recorded sign-off at the end.

Other kinds of acceptance testing

UAT is the best-known kind, but ISTQB also names others:

• Operational acceptance testing: the team that will run the system (operations, IT, support) confirms they can operate it: backups, monitoring, recovery.
• Alpha testing: people outside the development team test in the developer's environment.
• Beta testing: outside users test in their own environment, usually before a wider launch.

Who does UAT?

UAT is done by the intended users or the client: business users, product owners, or the client's own team. The development team supports them but doesn't run the tests on their behalf.

Typical roles:

• Client or business users: run the test scenarios and give the final decision.
• Project manager: plans UAT, agrees the scope and timeline, collects feedback, and gets sign-off.
• QA: prepares the environment and test data, helps write scenarios, and verifies reported issues.
• Developers: fix confirmed defects during the UAT window.

If the developers or QA test the software and call it UAT, it isn't acceptance testing. It's just more QA.

QA vs UAT: what's the difference?

The two don't replace each other. QA catches defects early, so that UAT can focus on fit and acceptance instead of basic bugs.

UAT vs SIT, smoke testing and regression testing

These terms often appear together in release plans:

The UAT environment: where UAT fits

Work should move through separate environments in order, with a check at each step. These are the four I use:

Naming varies between companies. Some call pre-production the UAT environment, and some use "staging" for what this table calls pre-production. The names matter less than the rule: the client only reviews work that has already passed QA, and production only receives work the client has accepted.

A UAT environment should be as close to production as practical: same configuration, realistic (but anonymised) data, and the same integrations, so that what the client accepts is what users will actually get.

The UAT process, step by step

1. Agree the scope. List the features and user stories included in this round of UAT.
2. Confirm acceptance criteria. Use the criteria written with the requirements. If they're missing, agree them now, before testing starts.
3. Prepare the environment and test data. Deploy the QA-passed build to pre-production, with test accounts and realistic data.
4. Write UAT scenarios. Turn each user story into a real task the client can follow (see the example below).
5. Run UAT. Give the client a fixed testing window and one place to report feedback.
6. Triage feedback. Sort each item into a defect (doesn't meet the agreed criteria) or a change request (new or different from what was agreed). Defects get fixed; change requests are estimated and planned.
7. Fix and retest. Confirm each fix (confirmation testing) and re-run regression checks on related features.
8. Sign off. Record the client's acceptance in writing: what was tested, which build, any known issues accepted, and who approved it.

UAT test case example

A UAT scenario describes a real task in the user's language, not a technical test step:

Release-readiness checklist

UAT is one gate among several. A quality gate is a checkpoint where a predefined set of quality criteria decides whether work can move to the next stage. Instead of one big test at the end, quality is checked at each step, while problems are still cheap to fix.

Gate 1: Ready for QA

Before a feature moves to staging:

• Acceptance criteria are met
• Code is reviewed
• Automated tests pass
• Developer has tested the main paths
• Known limitations are noted

Gate 2: QA passed

Involving QA during development means test cases are ready when the feature is. Before a feature goes to the client:

• Functional tests passed against acceptance criteria
• Edge cases and error states tested
• Tested on required devices and browsers
• Regression checks done on related features
• No open critical or high-severity bugs

Gate 3: UAT sign-off

• Client has tested the agreed scenarios in pre-production
• Every piece of feedback is either fixed and retested, or logged as a change request
• Any known issues are listed and accepted by the client
• Client has given written sign-off for this build

Written sign-off matters. It closes the loop and prevents disagreements after release about what was agreed.

Gate 4: Release readiness

Before deploying to production:

• All included items passed QA and UAT
• Release notes written
• Database changes and migrations reviewed, with a way to reverse them
• Configuration and environment variables checked for production
• Backup taken and rollback plan ready (or risky features behind a feature flag that can be switched off)
• Release time agreed with the client, avoiding peak usage
• Monitoring and alerts in place to spot problems quickly
• Team available after release in case something goes wrong

After release

• Smoke test the main user flows in production
• Confirm with the client that the release is live
• Watch logs and error reports for the first hours
• Note anything to improve for the next release

For larger systems, consider releasing gradually: deploy the code with a feature turned off behind a feature flag, then switch it on for a small group of users first. If something goes wrong, you can switch the feature off without redeploying. To see whether releases are getting safer over time, the DORA metrics track, among other things, how often deployments need an immediate fix or rollback (change fail rate) and how long it takes to recover.

Common UAT mistakes

• Treating UAT as the first real test. If the client finds basic bugs, QA came too late. Bugs found at the end push the release date.
• Clients testing unfinished work. It creates confusion and noisy feedback. Only QA-passed builds go to UAT.
• No acceptance criteria. Without them, every opinion becomes a defect and UAT never ends.
• Mixing defects with change requests. New ideas are welcome, but they need an estimate and a plan, not a quiet fix before release.
• An open-ended UAT window. Agree the dates up front, and what happens if feedback arrives late.
• Verbal sign-off. "They said it looked fine" isn't the same as written acceptance.
• No rollback plan. When something goes wrong in production, there's no quick way back.

Frequently asked questions

What does UAT stand for?

UAT stands for user acceptance testing. It's the last testing stage before release, where the client or intended users check that the software meets their needs and decide whether to accept it. In tech and business contexts, "UAT" can also refer to the UAT environment, the production-like environment where this testing happens.

Who performs UAT?

UAT is performed by the intended users: the client, business users, or a product owner representing them. The project manager plans it and collects sign-off, QA prepares the environment, test data, and scenarios, and developers fix confirmed defects. If only the development team tests, it's QA, not acceptance testing.

What is the difference between QA and UAT?

QA checks that the software works correctly against the requirements and doesn't break existing features. It's done by QA engineers, mostly in staging. UAT checks that the software meets the client's real needs, is done by the client or end users in a production-like environment, and ends with a decision to accept the release or not.

Is the UAT environment the same as staging?

Not always. Naming varies: some teams use staging for QA and a separate pre-production or UAT environment for client testing, while others run both in one staging environment. What matters is that UAT happens in an environment as close to production as possible, with work that has already passed QA.

What is the difference between smoke testing and UAT?

Smoke testing is a quick check that the most important functions work, done on a new build before deeper testing, or right after a deployment. UAT is a full acceptance check by the client or intended users of whether the software meets their needs. A smoke test takes minutes; UAT usually takes days.

What happens if UAT fails?

Each issue is triaged. Defects that break the agreed acceptance criteria are fixed, retested, and sent back for another round of UAT. Requests for new or different behaviour become change requests with their own estimate. The release goes ahead only when the client signs off, sometimes with minor known issues they've formally accepted.

Final thoughts

UAT isn't a formality at the end of a project. It's the moment the client confirms that what was built is what they needed. With QA during development, separate environments, and a clear checklist at each gate, release day becomes the least exciting day of the sprint.

Related: How to Write User Stories and Acceptance Criteria · Why Software Projects Get Delayed · How I Track 10 Projects at Once