On this page5 sections
ReferenceIntermediate4-6 min reference

UAT Quick Reference

User Acceptance Testing is the final check that the software does what the business needs — run by or for real users, not QA validating its own work. It answers "should we ship?" not "does the code work?". This sheet is the quick reference for roles, criteria, and evidence; for sign-off mechanics see the release resources linked below.

UAT vs the rest

UATSystem/QA testing
AsksDoes it meet business needs?Does it work as specified?
Run byBusiness users / product / clientQA / engineering
AgainstAcceptance criteria, real scenariosRequirements, test cases
EnvironmentUAT/staging, production-like dataTest environments
OutcomeGo / no-go sign-offBug reports

Entry criteria (before UAT starts)

  • System/regression testing complete; no open criticals/blockers.
  • UAT environment ready with production-like data.
  • Acceptance criteria and UAT scenarios agreed.
  • Participants identified and available.

Exit criteria (to sign off)

  • All planned UAT scenarios executed.
  • No open critical/high defects (or each has an agreed waiver).
  • Acceptance criteria demonstrably met.
  • Formal sign-off recorded by the business owner.

Evidence to capture

Executed scenarios + results, screenshots/recordings, the defect list with severities and decisions, and the signed-off acceptance record (who, when, what version).

Common mistakes

  • QA doing UAT for the users — it's the business's acceptance, not ours.
  • Starting UAT with criticals still open (it becomes re-testing).
  • No agreed acceptance criteria, so "done" is subjective.
  • Verbal sign-off with no recorded evidence or version.
  • UAT on unrealistic data, missing real-world cases.