User Acceptance Testing (UAT)

In User Acceptance Testing, the people who will actually use the software - finance clerks, support agents, warehouse staff, product owners - work through realistic business scenarios and decide whether the system is acceptable for go-live. It is the one test phase owned by the business rather than by QA: system testing verifies the software against its documented specification, while UAT verifies it against reality - real workflows, real data shapes, and the domain knowledge that never made it into a requirements document. Earlier phases prove the software was built right; UAT proves the right thing was built.

For teams working in Jira, UAT is famously awkward. Jira has no native concept of a test case, a test run, or a sign-off, so UAT usually escapes into spreadsheets, Word documents, and email threads. Business testers will not learn a technical QA tool just to participate, results scatter across attachments and inboxes, and when a sponsor or auditor asks "who accepted this requirement, against which build?" nobody can answer from one place. Closing that gap is one of the most common reasons Jira teams adopt a test management app in the first place.

UAT vs. system testing (the distinction that matters):

• •Who executes: System testing is run by QA professionals; UAT is run by business users or their designated subject matter experts
• •What it checks: System testing checks conformance to documented requirements; UAT checks fitness for real business use
• •How it is written: System tests speak in technical terms; UAT scenarios are written in business language a non-tester can follow
• •What it produces: System testing produces pass/fail results and defects; UAT produces a formal acceptance decision

Entry criteria - do not start UAT until:

• •System testing is complete and critical/high defects are closed (UAT on an unstable build burns tester goodwill you cannot get back)
• •The UAT environment is ready with production-like, anonymized data at realistic volume
• •UAT scenarios are written in business language and mapped to the requirements they validate
• •Testers are named, trained on how to record results and report issues, and have time actually blocked in their calendars
• •Triage rules are agreed: what counts as a defect, what counts as a change request, and who decides
• •Sign-off owners are named per area, with a defined quorum for go-live approval

What a UAT cycle looks like in practice:

1. Kickoff: walk testers through scope, the scenarios assigned to them, how to record results, and the deadline

2. Execution window: typically 3-10 working days; testers work through their scenarios while QA supports with environment issues and questions

3. Daily triage: review new findings, classify each as defect, change request, or works-as-designed, and prioritize fixes

4. Fix and retest: blocking defects are fixed and the affected scenarios re-executed within the window

5. Sign-off review: walk through results per requirement or business area with the sign-off owners; unresolved items get an explicit accept-with-known-issue or no-go decision

6. Recorded approval: capture who approved what, against which build, with results attached - not a vague "UAT passed" email

Who signs off: a named business owner per requirement or functional area - typically the product owner, the department head whose team will live with the system, and in regulated contexts a compliance officer. Sign-off should be recorded at the level of individual requirements or acceptance criteria, against a specific build. "The business signed off" with no record of who, on what scope, against which version is the ambiguity that turns post-release disputes into archaeology.
The common failure modes:

• •Testers ghost. UAT participants have day jobs, and without executive sponsorship and blocked calendar time they silently stop testing mid-window. Countermeasures: short focused windows, small scenario sets per tester, and visible progress tracking that makes non-participation obvious on day two instead of the deadline.
• •Defects vs. change requests blur. Users surface "this is broken" and "I wish this worked differently" in the same breath. Without agreed triage categories, change requests masquerade as blockers and the release slips. Classify every finding explicitly: critical defect (fix before release), minor defect (fix in a later release), change request (backlog).
• •Sign-off ambiguity. Nobody defined who has the authority to accept, what scope each approval covers, or what happens to items accepted with known issues. Define the sign-off model in the entry criteria, not in the final week.
• •Rubber-stamp UAT. If UAT consistently finds zero issues, it is not being done seriously. Real users use unexpected data, follow non-linear paths, and notice requirement gaps QA cannot see; zero findings usually means QA quietly executed the scenarios on behalf of absent users.

The formality scales with risk: a bank may run 50 testers through a 4-week UAT with regulator-mandated sign-off documentation, while a SaaS team may run a 2-day session with the product owner and two power users. The principle is constant: the people who will use the software validate it before it goes live, and their acceptance is recorded unambiguously.