Goal
The client verifies the product against the acceptance criteria signed during Requirements specification — not against gut feeling.
Inputs → outputs
Inputs
- Signed acceptance criteria
- Test and security reports
- UAT / staging environment
Deliverables
- UAT plan & scripts
- Findings list with status
- Signed acceptance certificate
Teams & roles
- Client (Product Owner / sponsor)performs UAT and signs acceptance
- Business Analysis (BA)writes UAT scripts, guides users
- Quality Assurance (QA/QC)supports, logs and reproduces defects
- Project Management / Scrum Mastercoordinates, triages findings
- Engineering (FE · BE · Mobile)fixes defects during UAT
- Support & Customer Successprepares post-go-live support
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | BA | PM | Dev | QA | Ops | Data | Legal | Client |
|---|---|---|---|---|---|---|---|---|
| UAT plan & scripts | A | · | · | R | · | · | · | C |
| UAT environment & data | · | · | · | C | A | R | · | · |
| Execute UAT | C | · | · | C | · | · | · | A |
| Triage findings (defect / CR / later) | R | A | · | · | · | · | · | C |
| Fix & re-run | · | · | A | R | · | · | · | · |
| Sign the acceptance certificate | · | R | · | · | · | · | I | A |
BA = Business Analysis (BA); PM = Project Management / Scrum Master; Dev = Engineering (FE · BE · Mobile); QA = Quality Assurance (QA/QC); Ops = DevOps / SRE; Data = Data & AI; Legal = Legal & Finance; Client = Client (Product Owner / sponsor)
Quality gate
Acceptance certificate signed.
Entry criteria
- System testing passed its gate (no Critical/High defects)
- UAT scripts approved by the client
- Real users are booked
Exit criteria
- 100% of UAT scripts executed
- No acceptance-blocking defects
- Remaining findings triaged with a plan
- Certificate signed by an authorised person, stating the build version
- The matching payment milestone is triggered
Activities
- 1.Prepare UAT scripts from acceptance criteria, with near-real data
- 2.Walk key users through the UAT / staging environment
- 3.Log findings and triage: defect, change request, later improvement
- 4.Fix and re-run UAT
Checklist
Tick to self-review — 0/5. Ticks stay in this browser only and are not sent anywhere.
Document templates
Markdown (.md) files: open in any editor, or paste into Word / Google Docs. Each states its purpose, who fills it in and when.
Client involvement
- Commit real users’ time to testing
- Sign the acceptance certificate once criteria are met
Tools
- Môi trường UAT / staging
- CT Work / Jira
- Loom (quay lỗi)
Reference standards
- ISTQB® — Acceptance testing
- User, operational and contractual acceptance testing
- ISO/IEC 25010:2023
- Reuse the quality model to check NFRs
Common pitfalls
- UAT turning into a new requirements round
- The builders doing the acceptance testing
- Not recording which build was accepted
- Verbal acceptance
Real example
Applied to LabFlow AI: UAT scripts come straight from the SRS acceptance criteria and run per role — Student books, Lab Staff checks in by QR, Lab Manager approves — each script is a CT Work card tracking pass / fail and traced back to its requirement through the RTM.
Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.