UAT answers a different question from system testing
System and integration testing ask whether the software behaves as specified. User-acceptance
testing asks whether the specified behaviour lets the business do its work and get the outcome
it paid for. Those are different questions, and conflating them is the most common way UAT
gets wasted: a phase where business users re-execute the test team's scripts, find the same
defects a fortnight later, and sign a form.
The consequence for design is that a UAT scenario should be a piece of the user's actual job,
end to end, in their own words. Not "verify the referral flag is set when gross value exceeds
the limit" — that is a system test that already ran. Instead: "take these four claims from
last month's post, process them as you normally would, and tell me what you cannot do." The
second form finds the things specification-conformance testing structurally cannot: that the
new screen requires a field the post does not contain, that the workaround the team relies on
has been designed out, that the volume achievable per hour has halved.
Plan it backwards from the outcome
Start from the objective in the business case rather than from the requirements list, and ask
what would have to be demonstrably true for that objective to be achievable. If the outcome is
reducing median corporate onboarding from eleven days to two, then UAT has to include a timed
run of a realistic application by someone who does the job, not a click-through of each screen
in isolation. Objectives generate scenarios that requirements do not.
Then scope by risk and volume rather than by coverage ambition. You will not test everything,
so choose deliberately: the highest-volume paths, the paths where an error costs money or
breaches an obligation, anything touching a regulatory control, everything that changed for
existing users, and the migration of existing data. Say out loud what you are consciously not
testing, and put that list in the plan — an untested area that is acknowledged is a risk, and
one that is unacknowledged is a surprise.
Who tests matters as much as what is tested. You want the people who do the work daily,
including one sceptic and one person who is fast at the current process, and you want them
released from their day job in writing with their manager's agreement. Business analysts and
project staff are the worst possible testers for this purpose, because they know what the
system expects and unconsciously avoid the paths a real user would take. Plan around real
people's availability, since month-end close and audit season will beat your test window
without negotiation.
The item that actually sinks UAT is data and environment. A representative, refreshed,
correctly masked dataset with the awkward historical records in it — the customer with two
addresses, the policy mid-endorsement, the claim reopened after closure — needs an owner and a
date weeks earlier than people plan for. Testers given clean synthetic data will pass a system
that fails in week one of production.
Traceability that makes coverage arguable
Coverage is a claim, and a claim needs a structure behind it. What you want is a chain from the
objective to the result, so that you can answer both directions: what proves this objective is
served, and why does this test exist.
| Objective | Requirement | Story | UAT scenario | Tester | Result |
|---|
| O1 Median onboarding under 2 working days | R4 Credit decision requested automatically on submission | ONB-112 | U1 Onboard a sole trader end to end, timed, from a real application pack | Ops, R. Patel | Pass, 46 min |
| O1 | R7 Application resumable after interruption | ONB-118 | U2 Abandon at director stage, resume next day, complete | Ops, R. Patel | Pass |
| O1 | R9 Cap of GBP 5,000 until credit clears | ONB-131 | U3 Activate uncapped account, attempt GBP 6,000 payment, confirm rejection | Credit, S. Ahmed | Fail, D-207 |
| O2 No increase in sanctions-screening misses | R12 Manual review queue for partial name matches | ONB-140 | U4 Process a known partial-match case from the April sample | Financial Crime, J. Obi | Pass |
| O2 | R13 Reviewer decision recorded with rationale | ONB-141 | no scenario | — | Gap, accepted |
Read down the objective column and you can see coverage as the business understands it. Read
the last row and you can see the value of the structure: an objective with a requirement and a
story but no acceptance scenario, visible before sign-off rather than after. That single empty
cell is the artefact's whole purpose, and it is why tracing to objectives beats tracing only to
requirements — a requirements-only matrix would have shown this as fully covered.
Entry and exit criteria, including the ones people skip
Entry criteria are the ones with teeth, because starting UAT unready is how a three-week window
becomes one. Insist that system and integration testing are complete with results shared, that
no known defect of high severity is open in scope, that the environment is stable and the data
loaded, that the scenarios are written and walked through with the testers, and that a triage
process and a daily slot exist before day one. The two most often skipped are the tester
briefing and the agreed defect-severity definitions, and both cost you a week of arguing about
whether something is a defect.
Exit criteria should never be zero defects, because that gate is either fictional or it delays
go-live over cosmetic findings. Use instead: every in-scope scenario executed, no open defect
above the agreed severity threshold, a written known-issue list with owners and target dates,
and any workaround documented and accepted by the operational team that has to live with it.
That last one is frequently the honest crux of a go-live decision.
Be explicit about what sign-off means when you ask for it. Say that the signature means the
business accepts that these scenarios executed with these results and this list of known
issues, and that it is not a claim that the system is defect-free. Ambiguity here is what makes
the next section happen.
When the business signs off on the wrong thing
It happens, and the good response begins by refusing two tempting moves: pointing at the
signature, and reopening the sign-off as though the paperwork were the problem. Both make you
an adversary of the only people who can fund the fix.
First diagnose, because the remedies differ completely. The requirement may have been wrong
from the start, meaning analysis missed the need. The need may have changed since the business
case, which is nobody's failure and a straightforward change. UAT may have tested conformance
to the specification rather than fitness for the job, which is a test-design failure and is by
far the commonest cause. The testers may have been proxies rather than practitioners, so the
paths that matter were never run. Or the outcome may depend on something outside the software
entirely — training, a process step, a change to incentives — which no amount of building
fixes.
Then quantify the gap against the original objective, not against opinion. "Median onboarding
is 6.5 days against a target of 2, and the cause is that 40 per cent of applications wait for
a credit decision the new flow still blocks on" is actionable. "Users are unhappy with it" is
not. This is where analytical work earns its place in a BA role: you need the measurement
before you need the meeting.
Then raise it as a change with its own case: the gap, the cause, the options, the cost of each,
and what the benefit is worth. It competes with everything else for funding and may lose, which
is a legitimate outcome. If it loses, record the residual gap against the objective so that the
benefits review does not later treat the shortfall as a mystery.
And do the honest retrospective. Where in the chain did the objective stop being represented?
Usually you will find that the scenarios were written from the requirements after the build,
by the person who wrote the requirements, and nobody ever asked whether passing them implied
achieving O1.
That sentence is the distinction the question exists to test, and most answers never reach it.
A signature obtained against scenarios derived from the specification can only ever confirm that
the system matches the specification. If the specification did not fully serve the need, the
signature confirms the mismatch and formalises it. The defence is structural rather than
diligent: scenarios derived from business objectives, executed by people who do the work, on
data that looks like the real corpus, with the untested areas named — plus, for anything with a
measurable business outcome, a post-implementation review scheduled at the time of sign-off
rather than promised vaguely for later.
UAT is not the last stage of testing the software; it is the first stage of finding out
whether the business can actually do its job with it. If your scenarios come from the
specification rather than from the objective, a clean pass tells you nothing about that.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).