What is user acceptance testing (UAT)?

How UAT differs from other testing

Quality assurance asks whether the software works as specified. UAT asks whether what was specified was the right thing.

That is a genuinely different question, and it is the one that catches the most expensive class of failure: a feature built exactly to specification that does not solve the problem it was commissioned for. No amount of QA finds that, because by its own terms nothing is broken.

Running it properly

• Real users or their genuine representatives, not the project team acting as proxies.
• Real scenarios, taken from actual work rather than from the specification.
• Realistic data, since clean test data hides the problems that messy real data causes.
• Defined acceptance criteria agreed before testing, or the outcome becomes an argument about opinion.
• Authority to reject. UAT that cannot stop a release is a ceremony rather than a gate.

Why it is usually done badly

UAT sits at the end of a project, which is where the schedule pressure has accumulated. By the time it runs, the release date is committed and the appetite for a finding that delays it is close to zero.

The predictable result is UAT as confirmation rather than testing: a scripted walkthrough that verifies the demo path works, conducted by people who already know the answer everyone wants.

Running it earlier — on a partial build, against real scenarios, with genuine authority to change direction — is more disruptive and considerably cheaper than discovering the requirement was wrong after launch.