What is UAT (user acceptance testing)? A plain guide

What UAT actually means

UAT stands for user acceptance testing. It is the stage where the people who will use the software, or those who speak for them, confirm it does the job in real conditions. Earlier testing asks whether the code works. UAT asks a harder question, whether the product solves the problem it was built for.

It is the last gate before go-live. By the time you reach it, functional bugs should already be caught. UAT is about fit, not first-pass quality.

• It checks business outcomes, not just features.
• It runs against acceptance criteria agreed up front.
• It is signed off by users or product owners, not developers.

Who runs UAT and when

UAT belongs to the business side. Real users, product owners, or domain experts run the scenarios, because they know what correct looks like in daily work. A QA partner sets up the environment, writes clear test scripts, and records results so nothing slips through.

The timing matters. Run UAT after system and regression testing have settled the build, but before release. Too early and you waste users on known bugs. Too late and there is no time to fix what they find.

UAT is not a second round of QA. It answers one question. Would a real user accept this as done?

How to run UAT well

Write acceptance criteria before you build, in plain language. Each criterion should be testable, so anyone can tell pass from fail. Then turn those criteria into short scenarios that follow real workflows, not isolated clicks.

• Use realistic data, so users recognise the product as their own.
• Keep sessions focused, with clear steps and an obvious result.
• Log every issue with what was expected and what happened, so fixes are fast.

Pairing scripted UAT with exploratory and UAT testing catches both the gaps you planned for and the ones you did not. Senior testers know where real users go off-script, so you find problems before customers do.

Common UAT mistakes

The biggest one is treating UAT as a formality, a sign-off rushed through on the last afternoon. That turns it into theatre. The second is vague criteria, where pass depends on who is looking. Both let defects reach production.

Industry guidance like the ISTQB glossary treats acceptance testing as a distinct level with its own discipline, and the W3C evaluation guidance is worth a read when accessibility is part of acceptance. Build that rigour in and UAT becomes a real safety net.

Want UAT that gives a clear yes or no instead of a shrug? A short testing audit shows where your acceptance process can tighten up, so you release on evidence.