User Acceptance Testing (UAT) is the final phase of software testing, where actual end users or business stakeholders verify that the system meets business requirements in real-world scenarios. UAT is the last gate before production release.

UAT differs fundamentally from earlier testing levels. QA engineers test against specifications; UAT testers validate against business needs. A feature can pass every system test and still fail UAT because it does not fit how people actually work.

Types of Acceptance Testing

• Alpha testing — internal staff test in a controlled environment before external exposure
• Beta testing — a limited group of real customers tests in production conditions
• Contract acceptance testing — verification against contractually agreed criteria
• Regulatory acceptance testing — verification against legal or compliance requirements
• Operational acceptance testing — backup, recovery, maintenance, and security workflows

The UAT Process: 6 Steps

1. Plan — define scope, entry/exit criteria, schedule, and participants
2. Design test scenarios — based on real business workflows, not technical specs
3. Prepare environment and data — production-like environment with realistic data
4. Execute — business users run scenarios and log results
5. Triage defects — classify as blocking vs. non-blocking; fix and re-test
6. Sign off — formal acceptance decision documented by stakeholders

UAT Entry and Exit Criteria

Entry criteria (UAT cannot start until): system testing complete, all critical and high-severity defects resolved, UAT environment ready with realistic data, test scenarios reviewed by business stakeholders.

Exit criteria (UAT is done when): all planned scenarios executed, no open blocking defects, business stakeholders provide formal sign-off, known minor issues documented with workarounds.

UAT Checklist

• Business requirements mapped to test scenarios — every requirement covered
• Real-world data sets prepared (anonymised production data where possible)
• End-to-end workflows tested, not isolated screens
• Edge cases from actual business operations included
• Defect logging process and severity definitions agreed in advance
• Sign-off template and decision owners identified before testing starts

Common UAT Mistakes

• Treating UAT as repeat system testing — UAT should follow business workflows, not technical test cases
• Starting UAT with open critical defects — testers waste time rediscovering known issues
• No dedicated time for business users — UAT squeezed into spare hours produces shallow coverage
• Skipping documentation — undocumented acceptance creates disputes later

Many organisations bring in an external QA partner to coordinate UAT — preparing scenarios, managing defect triage, and keeping business testers productive. See our guide on how to outsource software testing.

Frequently Asked Questions: UAT

Who performs user acceptance testing?
Business users, product owners, or client representatives — people who understand the business process the software supports. Not the QA team that performed system testing.

How long should UAT take?
Typically one to four weeks depending on application complexity. The schedule should be defined in the UAT plan with dedicated tester availability.

What is the difference between UAT and system testing?
System testing verifies the software meets its technical specification, performed by QA engineers. UAT verifies it meets business needs, performed by end users. See our breakdown of all functional testing types.

Can UAT be automated?
The core of UAT is human business judgment, which cannot be automated. However, automated smoke tests can verify the UAT environment is stable before business testers begin, saving significant time.

Need help structuring UAT for a major release? Hire a dedicated QA team from Astaqc or contact us.