User Acceptance Testing

User acceptance testing (UAT) is the last check a build faces before it goes live. Real users sign it off, not the test team, judging it against the acceptance criteria set at the start of the work, not invented at the end.

UAT answers a different question from the testing that came before it. Earlier stages ask whether the code works. UAT asks whether the thing that was built is the thing the business actually needed.

The people doing it are the ones who will live with the result — claims handlers, schedulers, finance clerks, agents on the floor. They are not professional testers, and the process has to be designed around that.

Outsourced builds raise the stakes. Business users sit with the client and engineers sit with the provider, so UAT is where both sides find out whether the brief survived the handover.

Key takeaways

• UAT is the final validation stage before release, owned by business users rather than by quality assurance.
• Every test traces back to an acceptance criterion agreed before the build started.
• Entry and exit criteria decide when UAT can start and when it is genuinely finished.
• Realistic test data in a production-like environment is what separates useful UAT from theatre.

How it works

UAT runs once system and integration testing has passed, in an environment that mirrors production. Nominated business users work through scripted scenarios and real edge cases, record a pass or fail against each acceptance criterion, and raise defects for triage.

Each test has a binary verdict. Agile Alliance’s glossary describes an acceptance test as a formal description of product behaviour that generally returns a pass or a fail, with no partial credit.

Gates sit on either side of the window. NASA’s Software Engineering Handbook sets entrance criteria for a System Acceptance Review that include baselined acceptance criteria, acceptance test readiness and a documented process for analysing results.

Acceptance criteria do the heavy lifting. Written at the start of the work in the business’s own language, they are what each UAT script is traced back to, which keeps the testing honest.

Test data is the quiet failure point. Scrubbed production extracts beat invented records, because users spot wrong behaviour fastest on transactions they recognise.

Someone has to coordinate the window. A UAT lead schedules testers, chases stalled scripts, keeps the defect log current and produces the evidence pack the business owner signs.

Defect triage during UAT is a judgement call, not a queue. Each finding gets classified as a defect, a change request or a misunderstanding, and only the first of those blocks the gate.

Alpha and beta are the public-facing cousins of UAT. The UK government’s service manual runs services through discovery, alpha, beta and live phases so that real users meet the thing long before launch day.

Examples

UAT looks different by sector, but the shape holds: named business users, a frozen build, scripted scenarios and a dated sign-off. Three settings show how the same gate adapts to very different risk levels and user populations.

A retail bank migrating its core platform puts branch staff and call-centre agents through UAT scripts for several weeks before a cutover weekend. Anything unresolved becomes a documented accepted risk, signed by a named executive.

An insurer replacing its claims system runs a two-stage pass — an internal alpha with a small handler group first, then a wider beta across regional offices. Defect density is tracked per module between the two stages.

A Philippine BPO delivering an order-management build for a US retailer hosts the UAT environment itself. The client’s warehouse supervisors test during their own working hours.

That is why providers running software testing outsourcing engagements plan the UAT window around the client’s timezone — not their own — and staff a bridge call for the overlap.

Related terms

UAT sits at the end of a chain of quality practices, and it borrows people and artefacts from several of them. The entries below cover the roles, metrics and delivery stages a UAT plan touches on its way to sign-off.

• Quality Assurance: the broader discipline of building checks into a process rather than inspecting at the end.
• Beta Testing Program: the structured release of a near-final product to real users outside the build team.
• Test Engineer: the specialist who designs and automates the technical test layers that run before UAT.
• Software Quality Assurance Outsourcing: the practice of contracting an external team to own testing capability.
• Minimum Viable Product: the smallest release that can be validated with real users.

FAQ

Who should run user acceptance testing?

Business users who will use the system daily, supported by a coordinator who manages scripts, defects and sign-off. Quality assurance facilitates but does not give the verdict.

How is UAT different from system testing?

System testing checks that the software meets its technical specification. UAT checks that it meets the business need described in the acceptance criteria.

What are UAT entry and exit criteria?

Entry criteria are the conditions that must hold before testing starts, such as a stable build and loaded test data. Exit criteria define a finished UAT, usually zero open critical defects and a verdict against every criterion.

How long should UAT take?

It depends on scope and risk, but two to four weeks is common for a mid-sized release. Regulated or high-volume platforms run longer.

What happens to defects found during UAT?

Each one is logged with a severity, then triaged as a defect, a change request or a misunderstanding. Only unresolved critical and high defects hold the exit gate.

Can UAT be outsourced?

Coordination, environments and scripting can be, but the sign-off itself has to stay with the business users who own the outcome.

Compare vetted providers in the Outsource Accelerator directory if you need a delivery partner that takes UAT planning seriously.