User acceptance testing (UAT) is the phase where business representatives verify that software supports their real processes acceptably before production release. It answers a different question from engineering QA: not only “does it work as coded?” but “can we run the business on this?”
Skipping UAT is a common cause of go-live pain. Defects found by real users after launch cost more and damage trust. Vendor demos are not a substitute for business-led scenarios.
Who should participate
- Process owners who know edge cases
- Daily users from each critical role
- A coordinator who tracks scenarios, evidence, and sign-off
- Technical support ready to triage environment issues
Developers should support UAT, not replace business testers. If only the vendor tests, you have demonstration—not acceptance.
What good UAT looks like
UAT uses written scenarios derived from an SRS or acceptance criteria. Each scenario states preconditions, steps, and expected results. Testers use realistic data (anonymised if needed) and record pass/fail with screenshots or transaction IDs.
UAT cycle
- Prepare scripts and test data
- Train testers on the environment
- Execute scenarios by role
- Log defects with evidence
- Retest fixes and sign off
Entry and exit criteria
Enter UAT when critical features are complete enough, environments are stable, and known blocking bugs are resolved.
Exit UAT when agreed scenarios pass, remaining issues are classified (fix now / defer with workaround), and named owners sign acceptance.
Without exit criteria, UAT becomes an endless forum for new feature requests disguised as defects.
Common UAT failures
- Testing only the happy path
- No time reserved on calendars
- Unclear who can accept residual risk
- Changing major requirements mid-UAT without re-baselining
- Using empty or toy data that hides mapping problems
- Letting executives “click around” without scripts, then declaring pass/fail from vibes
How UAT connects to project timeline
UAT is often underestimated in timeline planning. Budget calendar space for at least one full pass plus a retest window. Protect a freeze on non-critical scope changes during that window. Preparation inputs from the checklist make scripts faster to write.
Writing strong UAT scripts
Each script should name the role, data setup, steps, expected result, and where to capture evidence. Include at least one negative case (insufficient permission, duplicate invoice, rejected approval). Translate business language into the screens and APIs testers will actually touch.
Defect severity that prevents arguments
Agree definitions up front: blocker (cannot go live), major (workaround painful), minor (cosmetic or rare). Sign-off can accept known minors with dates to fix. Without severity rules, every bug becomes a political negotiation.
UAT environments
Refresh staging data intentionally. Stale staging that does not resemble production tax codes or item lists produces false confidence. Document who may change staging configuration during the UAT window. Integrations should point to sandboxes, not silent production writes.
A concrete UAT scenario
Role: Credit Controller.
Precondition: debtor near credit limit; sales order awaiting approval.
Steps: open queue, review order total vs available credit, reject with reason, confirm sales notification.
Expected: order not fulfilable; audit log shows actor, time, and reason.
Evidence: screenshot + order ID. That script can pass or fail unambiguously.
FAQ
How many cycles are normal?
Plan for at least one full cycle and one retest cycle. Complex integrations may need more. Endless UAT usually signals unclear requirements or uncontrolled scope changes—not a need for infinite testing.
Who signs off?
A named business owner for each process area—plus an overall sponsor for residual risk. “The committee felt okay” is not sign-off.
Can we UAT in production?
Prefer a staging environment that mirrors production closely. Production UAT risks real customers and real ledgers. If unavoidable, isolate with test accounts and a written rollback plan.
What if UAT finds a big missing requirement?
Treat it as a scope change: re-estimate, re-baseline, and decide whether go-live slips or the item defers. Do not silently absorb major gaps into “just fix it before launch” without adjusting plan.
How is UAT different from training?
Training teaches people how to use the system. UAT proves the system meets agreed behaviours. Combine sessions carefully so training time does not replace scripted acceptance.
Related concepts
Requirements: what is an SRS. Delivery phases: how custom software development works. Prep: software project preparation checklist. Timeline: how long custom software development takes.