UAT (User Acceptance Testing): business users test the system to confirm it meets their needs before go-live.
Distinct from QA testing: QA tests against requirements (technical correctness). UAT tests against business needs (does it actually work for users?).
QA role in UAT:
1. Plan UAT.
- Test scenarios, sign-off criteria, schedule.
- Identify UAT users.
- Set up UAT sandbox with test data.
2. Train UAT users.
- How to test, what to look for, how to log defects.
3. Support during UAT.
- Field questions.
- Triage defects vs feature requests.
- Help users navigate.
4. Coordinate fixes.
- Defects logged.
- Dev triage.
- Fixes deployed to UAT.
- Re-test.
5. Sign-off.
- Document UAT completion.
- Track defects.
- Determine readiness for go-live.
Process:
- UAT environment: typically Full Sandbox with realistic data.
- Duration: 2-4 weeks typical.
- Cadence: daily standup, UAT review meetings.
- Defect triage: severity, owner, ETA.
Sign-off criteria:
- All Sev 1/2 defects resolved.
- All UAT scenarios passed.
- Stakeholder approval.
Common pitfalls:
- UAT done by wrong people — should be real users.
- UAT too late — defects pile up; release delayed.
- UAT environment not realistic — defects only show in production.
- UAT defects ignored — go-live with known issues.
Senior QA insight: UAT is the business validation step. Technical correctness ≠ business correctness. UAT catches the gap.
The senior framing: prepare UAT for success. Good UAT: clear scenarios, realistic data, engaged users, structured triage.