How do you plan and run UAT, and what happens if the business signs off something that does not meet the original need?

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.

Sign-off proves conformance, not fitness

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.