UAT Explained: Proving a System Is Fit for Purpose

User Acceptance Testing answers one question: does this system let the business do its work? Not "does it match the specification" — that was system testing — but "would the people who do this job accept it".

The distinction sounds academic until you watch a UAT phase in progress. Most of them are a second round of functional testing performed by tired business staff who were given a script, a deadline and no authority to say no. That is not acceptance; it is unpaid regression testing with a signature at the end.

What makes UAT different#

System testing verifies the system against what was specified. UAT validates it against what the business actually needs — including the things nobody thought to specify.

This is why UAT finds a distinctive class of problem: the workflow that is technically correct and takes eleven clicks where the old system took three; the report that is accurate and unusable in the meeting it exists for; the process that works for a standard case and has no path for the exception that happens forty times a week.

Those are not defects against the specification. They are defects against reality, and only somebody who does the job can see them.

Who should do it#

The people who will use the system, in their own roles, doing their own work. Not their managers, not the project team, and not a contractor hired to run through scripts.

That has consequences most projects underestimate:

• They need time released. UAT on top of a full workload produces box-ticking. If nobody is freed to do it, it will not be done properly, and the decision to accept will be uninformed.
• They need authority. If participants cannot cause a delay, their findings are advisory and everyone knows it.
• They need to represent the range. The experienced person will navigate around problems without noticing; the new starter will find them. Include both, and include the awkward regional or departmental variants.

Entry criteria — the part that saves the phase#

Agree these before UAT is scheduled, and hold to them:

• System testing complete, with known defects listed and severity agreed
• The environment stable, with realistic data volumes
• Integrations connected or their stubs explicitly agreed
• Test accounts with correct permissions, created and verified
• Participants trained on the new system
• A defect route that people can use in under a minute

🔴 Starting UAT on an unstable build is the single most common way a phase fails. Participants spend their limited time on defects the project team already knew about, lose confidence, and stop reporting anything.

Acceptance criteria that decide something#

Written before testing starts, in the business's language, and specific enough to be answered yes or no.

Weak: The system is easy to use.

Usable: A branch adviser can complete a standard new-customer application, end to end, without assistance, in under eight minutes.

Then agree, in advance, what happens if criteria are only partly met — which severities block go-live and which are accepted with a workaround. Deciding that during the phase, under deadline pressure, produces whatever answer the schedule requires.

Running it well#

Test real scenarios, not features. "Process a month-end close" exercises the system the way the business does. A feature checklist exercises it the way the specification does, and system testing already did that.

Use realistic data. Volumes that match production, records with history, the customer whose name breaks the address format. Clean, invented data hides most of what UAT exists to find.

Leave room for exploration. Scripts confirm what somebody already thought of. Give participants time to simply do their job in the system and report what got in the way — that is where the valuable findings come from.

Triage daily. A short daily session with the business lead, a tester and a developer keeps severity honest and stops a backlog of ambiguous reports accumulating.

Record the workarounds. Where a defect is accepted, the workaround becomes an operational instruction on day one. Undocumented, it becomes a support call.

Sign-off that means something#

Sign-off is a business decision, not a testing formality. The person signing should be able to state what was tested, what was not, what defects are being accepted and what the workaround is for each.

Shipping with known defects is normal and often correct. Shipping with known defects that were never written down is how the same issue is rediscovered by a customer three weeks later, with nobody able to say whether it was known.

Why UAT phases go wrong#

It becomes a second system test. The business is handed detailed scripts and asked to verify features. Everything is confirmed, nothing is validated, and the workflow problems surface after go-live.

Participants have no time. They test in the gaps between their real work, which means they test the happy path quickly and sign.

It starts too late. Scheduled as the last phase before a fixed date, its only possible outcome is approval. If UAT cannot change the date, it cannot change anything.

Defect severity is decided by the project. When the team under deadline pressure grades its own defects, medium becomes the most popular severity in the world.

No environment discipline. A build changing under the testers produces results nobody can trust and defects that cannot be reproduced.

A realistic starting point#

Name a business owner who will sign. Write ten to fifteen end-to-end scenarios covering the work the system exists to do, including two exception cases and one month-end or period-end process. Write acceptance criteria for each. Agree entry criteria and defect severities before booking the window. Release the participants' time formally. Run daily triage. Record accepted defects with workarounds and owners.

That is a phase that decides something, and it is achievable on an ordinary project.

FAQ#

How long should UAT take?#

Long enough to run the scenarios twice: once to find problems, once to confirm fixes. For a moderate system that is usually two to three weeks of part-time participation. A single pass with no time for a retest cycle means fixes go live unverified.

Can we automate UAT?#

Not really, and attempts to do so usually reveal that the phase was actually system testing. Acceptance is a judgement about fitness for purpose. Automate the regression suite so that retesting after fixes is fast — that is where automation helps this phase.

What if the business finds a defect that is really a missed requirement?#

Log it honestly as a change, not as a defect, and decide it commercially. Reclassifying missed requirements as defects to avoid a change conversation poisons trust, and re-labelling genuine defects as changes does the same in the other direction.

Who decides severity?#

The business, with the project team advising on effort and risk. Severity describes business impact; the team that has to fix it should not be the one grading how much it matters.

Should we run UAT in production?#

No — use a dedicated environment with production-like data. Where some behaviour can only be verified in production, do it as a limited, deliberate pilot with a named group and a defined rollback, and call it a pilot rather than UAT.

What if UAT fails?#

Then it worked. The phase exists to surface this before customers do. Present the specific criteria not met, the options — delay, reduced scope, go live with documented workarounds — and let the business decide. What it must not become is a quiet renegotiation of the criteria.

Do agile teams need UAT?#

The event may disappear; the validation does not. Continuous involvement of real users during delivery is better than a phase at the end. Most teams still hold a short structured acceptance period before a significant release, because the end-to-end view is different from story-by-story acceptance.

Related Articles#

Trace back to the FRD and SRS for what was specified, use the RTM to show every requirement was covered, and record what you learned in Lessons Learned.

What else is coming for UAT