Most UAT guides explain the phase and stop. This one gives you the artefacts: a filled-in test case, an execution log, a defect record and sign-off criteria, using one realistic scenario throughout so you can see how the documents connect.
The scenario is a B2B invoicing application adding partial payments. It is deliberately ordinary, because the shape of the paperwork matters more than the domain.
Who should run UAT, and who should not
UAT fails most often before a single case is executed, in the decision about who runs it.
The tester must be someone who does the job the software supports. Not a project manager, not a business analyst who gathered the requirements, and not the QA team. A business analyst knows what was specified, which means they test the specification rather than the work. The person who processes invoices daily knows that customers routinely pay slightly under the invoiced amount and expect the remainder written off, which is the kind of thing that never appears in a requirements document.
Three or four testers is usually the right number for a mid-sized release. Fewer and you get one person's habits. More and coordination costs exceed the coverage gained.
Give them protected time. UAT squeezed around a day job produces rushed passes, because a tester under time pressure looks for reasons to mark something Pass rather than reasons to investigate.
When to run it
UAT sits after system testing and before release, and the sequencing matters more than the calendar.
Entry criteria worth enforcing: system testing complete with no open critical defects, the UAT environment loaded with production-shaped data, and the test pack reviewed by the business before execution starts. Entering UAT with known critical defects wastes the testers' time on failures QA already knows about, and it trains them to expect breakage, which makes them less likely to report the subtle defects you actually need from them.
The environment is the part that slips. UAT on a database of Test Customer 1 through Test Customer 50 will not surface the defect that only appears with a customer name containing an apostrophe, or an invoice dated 31 March in a financial year that ends that day.
What a UAT case must contain
A UAT case is not a QA test case with different wording. QA asks whether the software works. UAT asks whether the business can accept it, so the case is written in business language and executed by someone who does the job.
The field people skip is acceptance criteria, and it is the one that decides whether sign-off is a judgement call or a fact. "Payment applies correctly" is an opinion. "Invoice balance reduces by the payment amount and status changes to Partially Paid" can be verified by a finance clerk without asking an engineer.
A worked UAT test case
This is one complete case, filled in as it would be handed to a business tester.
Two things to notice. The steps use the language of the job, not the interface: "record a payment of 4,000" rather than "enter 4000 in the txtAmount field". And every expected result is observable by the tester without database access. For more, see our guide to writing better test cases.
The negative case that belongs with it
Business users test the happy path unless you explicitly give them the unhappy one. Pair every positive case with the rejection it implies.
If your UAT pack is all positive cases, you are not testing acceptance. You are running a demonstration.
The execution log
The log is the evidence trail. It answers, months later, what was actually run and by whom.
Keep the tester's real name, not "business team". When a defect is disputed after release, the value of this log is being able to ask the person who ran it what they saw. For more, see our guide to software tester roles and responsibilities.
A defect record a developer can act on
The commonest failure in UAT defect reports is describing a feeling rather than a reproduction. "Payments are not working properly" costs a developer an hour of guessing.
Poor:
> Partial payments are broken. The balance looks wrong sometimes.
Usable:
> UAT-D-014 · Partial payment rounds the balance to the nearest rupee > > Environment: UAT, build 4.2.0-rc3 > Test case: UAT-INV-007 > Steps: Open invoice INV-2026-0442 with balance 10,000.50. Record a payment of > 4,000.25 by bank transfer. Save. > Expected: Balance shows 6,000.25. > Actual: Balance shows 6,000.00. The 0.25 is lost, not deferred. > Impact: Every invoice with paise-level amounts will drift. Finance cannot reconcile. > Severity: High. Blocks sign-off. > Evidence: screenshot uat-d-014.png, attached.
The difference is not length, it is reproducibility. A developer can act on the second without a conversation.
Turning UAT results into a release decision
The pack is executed, the log is filled in, and someone has to decide whether to ship. That conversation goes better when the numbers are in front of everyone.
From the extract above: six cases executed, four passed, one failed with a high-severity defect, one blocked on environment. That is not a pass. It is also not a reason to stop the release, because the blocked case is an environment gap rather than a product defect, and it can be executed once rates are loaded.
The distinction that saves arguments is between Fail and Blocked. A failure is information about the software. A blocked case is information about your test environment, and counting it as a failure makes the product look worse than it is while hiding a real gap in your setup. Track them separately and report them separately.
Where a defect is deferred rather than fixed, write the deferral down with an owner and a date, inside the sign-off. A deferred defect with no owner is a defect that will be rediscovered in production by a customer.
Sign-off criteria, agreed before execution
Agree what "passed" means before anyone runs a case. Deciding afterwards turns sign-off into a negotiation under release pressure.
- Every high-severity case passes. No exceptions, no conditional sign-off.
- No open critical or high defects. Medium and low may be deferred with a named owner and a date.
- At least 95% of planned cases executed. Unexecuted cases are unknown risk, not passed risk.
- Each business area signs for its own scope. Finance signs the payment flows, operations signs the fulfilment flows. One person signing for everything means nobody read it.
- Deferred defects are listed in the sign-off itself, not in a separate document that gets lost.
Adapting the sample
The structure above transfers to most domains with three changes.
Swap the persona. The tester should be whoever does this task for a living. For a patient-records release that is a ward clerk, not a project manager.
Swap the data. Use production-shaped values, including the awkward ones: long names, non-ASCII characters, amounts with fractional currency, dates near month end. Clean round numbers hide the defects that matter.
Keep the acceptance criteria observable. If verifying a result requires a database query, it is a QA test, not a UAT case. Rewrite it so the business tester can confirm it from the screen in front of them.
Common mistakes
The most expensive of these is the first. UAT run by the QA team is not user acceptance testing, it is a second round of QA with a different label, and it will miss exactly the defects UAT exists to catch: the ones that are technically correct and wrong for the business.
If you want UAT designed and run by people who do it regularly, our software testing services cover UAT planning, execution and sign-off.