User Acceptance Testing: Process, Criteria and Templates in 2026

The Quick Answer

User acceptance testing is the final validation before release, performed by the people who will use or own the software, answering one question: does this do the job the business needs done?

The distinction that defines it: every earlier stage asks whether the software works as specified. UAT asks whether the specification was right. A feature can pass every functional test and still fail UAT because it solves the problem in a way the business cannot work with.

The output is a decision, not a report. UAT ends with a named person accepting the release, accepting it conditionally, or rejecting it. If there is no decision and no signatory, what happened was a demonstration.

This article covers the types of acceptance testing, entry and exit criteria that actually gate, who participates and who signs, how to plan a cycle, what business users need from a script, how defects are handled when the clock is running, and how UAT works in short iterations. It assumes the release plan already exists - for that, see our test plan guide.

What UAT Is and What It Is Not

UAT is validation, not verification. Verification asks "did we build it right" and belongs to the development and QA stages. Validation asks "did we build the right thing" and can only be answered by someone who owns the outcome.

Three things UAT is not, each of which is a common and expensive misuse:

It is not a second round of QA. If business users are finding broken buttons and validation errors, the release entered UAT too early. Their time is the scarcest resource in the process and it is being spent on work that should have been done before they arrived.

It is not a demo. A walkthrough where someone from the project drives and the business watches produces agreement in the room and surprises after release. Users must operate the software themselves, on their own scenarios.

It is not the place to gather requirements. New requirements will surface - that is a healthy side effect - but if UAT is where the business first sees what was built, the project has a discovery problem that UAT cannot fix at that price.

The Four Types of Acceptance Testing

Business acceptance testing is the standard case: internal users validate that the system supports their processes. Used for internal systems, enterprise software, and customer-facing products before release.

Contract acceptance testing validates against acceptance criteria written into an agreement. The criteria are fixed in advance, the tests map to clauses, and the outcome may trigger payment or penalties. Precision matters more than exploration here; ambiguity in a criterion becomes a commercial dispute.

Regulation acceptance testing validates compliance with legal or industry requirements - data protection, accessibility, financial or medical regulation. Evidence retention is part of the deliverable, and the audit trail matters as much as the result.

Alpha and beta testing move acceptance outside the delivery team - alpha with internal users in a controlled setting, beta with real customers in their own environment. Beta yields the most realistic feedback available and the least control over what gets covered, so it complements structured UAT rather than replacing it.

Most releases need one of these; regulated products often need two running in parallel with different signatories.

Entry and Exit Criteria

Criteria are what make UAT a gate rather than a phase name. Without them, UAT starts when the calendar says so and ends when someone runs out of patience.

Entry criteria - all must be true before UAT begins:

• All in-scope functionality is developed and deployed to the UAT environment
• System and integration testing complete, with results available
• No open defects of critical or high severity in scope
• The environment is stable, production-like and verified by a smoke pass
• Test data is loaded, realistic and sufficient for every planned scenario
• User accounts exist with the correct roles and permissions
• UAT scenarios are written and reviewed by the business
• Participants are identified, released from other duties, and trained on the changes
• The defect process, severity scale and communication channels are agreed

The entry criterion most often waived is the third, and waiving it is the single biggest predictor of a UAT cycle that overruns. Business users who hit a broken core path in the first hour lose confidence in the whole release and spend the rest of the cycle looking for further breakage instead of validating their processes.

Exit criteria - all must be true before sign-off:

• All planned scenarios executed, with results recorded
• Pass rate meets the agreed threshold - typically 95% or higher on critical scenarios, and 100% on those that are contractually or legally required
• No open critical or high-severity defects
• Every medium and low defect is either fixed, scheduled with a date, or formally accepted by the business
• Every fix delivered during UAT has been retested, plus a regression pass on what it touched
• Accepted defects and known limitations are documented and communicated to support
• Sign-off recorded by the named signatories

Write both lists into the plan and get them agreed before the cycle starts. Criteria negotiated during UAT are not criteria; they are whatever the deadline requires.

Who Runs It and Who Signs Off

UAT participants should be the people who will actually use the system, and they should span the range of real usage rather than being drawn from whoever is available.

• Daily users of the affected process, including at least one experienced person and one recent joiner - the second group finds the usability problems the first has learned to work around
• Someone from each affected role or department, since a process that works for one role frequently breaks for the next one downstream
• A support or operations representative, who will be answering questions about this in three weeks
• The product owner, coordinating and empowered to make scope decisions
• A QA contact, who prepares scenarios and data, triages what comes in, and translates between business language and defect reports - present but not performing the testing

Sign-off belongs to whoever is accountable for the business outcome - the process owner, the department head, or for contract work, the client's nominated representative. Name them in the plan on day one. A release waiting on "the business" to sign off is waiting on nobody in particular.

The recurring organisational problem is that the right participants have day jobs. Nominal allocation - "20% of their time" - produces testing squeezed into gaps, which produces shallow coverage and late findings. Either their time is genuinely protected and their workload covered, or the schedule should reflect what part-time participation actually yields.

Planning the UAT Cycle

A UAT cycle has a predictable structure and the preparation is the majority of it.

Two scheduling notes that prevent most overruns. Fix deployment needs a cadence, not a stream - daily or every other day, at a fixed time, with a note of what changed. Continuous deployment into an active UAT environment means users cannot tell whether they are testing what they tested yesterday. And build in a retest buffer: a cycle planned as two weeks of execution with no time for fixing and revalidating is a cycle that will finish late or sign off on untested fixes.

Environment and Test Data

More UAT cycles are damaged by environment and data problems than by defects in the software.

The environment must be production-like in configuration, not just in code version: same integration endpoints (or realistic stand-ins), same authentication, same roles and permissions, comparable data volumes. A UAT environment where a search returns four results and production returns forty thousand will not surface the performance and usability problems that matter.

It must be stable and exclusive. Deployments outside the agreed window, other teams using the same environment, or data being reset mid-cycle will invalidate results and burn goodwill that is difficult to recover.

The data has to support real scenarios. Business users test with their own cases - the customer with three subsidiaries, the order that was partially refunded last year, the account in an unusual state. Generic seed data cannot exercise those, and users will conclude the system was not built for their reality.

That creates the standard tension: the most useful data is production data, and production data in a UAT environment is a privacy exposure. The workable answer is masked or anonymised production data that preserves shape, distribution and relationships while removing identifying values - with the mask applied before the data leaves production, not after it lands. Whatever route you take, decide it early: sourcing and masking realistic data is measured in weeks, and it is a common reason UAT starts late.

Writing UAT Scripts That Business Users Can Follow

UAT scenarios are written for people who know the business and do not know the system. That drives every decision about how they are written.

Frame them as business processes, not features. "Onboard a new corporate client with two billing addresses" is a UAT scenario. "Verify the address field accepts 200 characters" is a QA test case that has wandered into the wrong document.

Use the language of the business. Their names for entities, their terminology for states, their sequence of work. Every technical term in a UAT script is friction that produces a question instead of a result.

State the expected outcome in business terms. "The client appears in the active client list and the welcome email arrives", not "a 201 response is returned".

Leave room for judgement. Alongside the prescribed steps, ask the question only they can answer: could you do your job with this? Some of the most valuable UAT findings are not defects at all - they are three extra clicks in a task performed four hundred times a day.

A workable script template is below. If you want a ready-made spreadsheet to start from, the UAT sheet in our test case templates guide takes a complementary angle, organized around acceptance criteria and business-owner sign-off rather than execution tracking. The script template:

Spreadsheets are the default vehicle for this and they cost more than they appear to. Versions diverge between participants, status is only visible when someone consolidates, and the results have no life beyond the cycle. Holding UAT scenarios as test cases and the cycle as a test run gives live progress, per-scenario history and reuse next release - which matters because most UAT scenarios are re-run every time the process changes.

Defect Handling and the Sign-Off Decision

Defects raised by business users arrive as descriptions of an experience - "it didn't save my changes" - and need a QA contact to reproduce, isolate and turn into an actionable report. Expecting users to file well-formed defects produces either poor reports or unreported problems.

Triage daily, and classify each item into one of four categories before deciding anything:

• Defect - behaviour contradicts the agreed requirement. Fix or defer by severity.
• Change request - the software matches the requirement and the requirement was wrong. Goes through change control; it does not silently become in-scope work.
• Training or documentation gap - it works, the user did not know how. Address, do not code.
• Environment or data issue - not a product defect. Fix the environment and re-run.

The second category is where UAT scope quietly doubles. Every request that gets absorbed as "just a small fix" extends the cycle and displaces the retesting the exit criteria depend on. Route them visibly, decide them explicitly, and let the business own the trade-off.

Sign-off then has three legitimate outcomes, and the middle one is the most common and the most abused:

• Accepted - exit criteria met, release proceeds
• Conditionally accepted - release proceeds with named open defects, each with an owner, a target date and an agreed workaround communicated to support. Only meaningful if the conditions are written down and tracked afterwards.
• Rejected - criteria not met, release does not proceed. A rejection that gets overruled without changing the criteria teaches everyone that UAT is advisory.

Record the sign-off with the release version, the scenarios executed and their results, the accepted defects, the conditions, and the signatory. In regulated contexts this is audit evidence; everywhere else it is the record of what "the business approved this" actually meant when the question comes up later.

UAT in Agile Delivery

In iterative delivery, UAT as a multi-week phase at the end of a project does not fit - but acceptance by users still has to happen, so it changes shape rather than disappearing.

Continuous acceptance within the iteration. The product owner accepts each story against its acceptance criteria as it completes. This is real acceptance testing, at story granularity, and it catches misunderstandings within days rather than months.

Periodic end-to-end validation. Story-level acceptance does not test whether a business process works across all the stories that touched it. A short cycle - a day or two per release or every few iterations - covers the process end to end with real users. This is where the process-level gaps appear.

Acceptance criteria as the shared artefact. Written before development, in business language, agreed by the product owner. They tell the developer what this story must do, alongside the team's Definition of Done rather than in place of it - the Definition of Done carries the shared conditions every increment must meet, such as regression, documentation and deployment readiness. The same criteria serve as the QA test basis and the acceptance script, which is what removes the need for a separate UAT design phase.

Release-level sign-off where it is required. Contractual and regulatory acceptance does not go away because delivery is iterative. Keep it, keep it evidenced, and keep it small by having validated continuously beforehand. For how these activities distribute across a sprint, see QA in agile.

Common Mistakes

• Starting before entry criteria are met. Business users doing QA's job, badly, at the worst possible moment.
• Participants who are not real users. Project team members role-playing produces sign-off without validation.
• No time protection. Nominal allocation yields nominal coverage.
• Unrealistic data. Users cannot validate their processes against records that do not resemble their own.
• An unstable or shared environment. Results that cannot be trusted, and participants who stop reporting.
• No agreed exit criteria. UAT ends when the deadline arrives rather than when the software is acceptable.
• Absorbing change requests as defects. Scope grows invisibly and the schedule absorbs it.
• No retest window. Fixes shipped during UAT that nobody revalidated are the most common source of immediate post-release escapes.
• Sign-off with no signatory. "The business approved it" with no name attached means nobody approved it.
• Results that die with the cycle. Next release starts from an empty spreadsheet, and the same scenarios are rewritten from memory.

Conclusion

User acceptance testing is the only stage that asks whether the right thing was built, and it is answered by the people who own the outcome rather than by the people who built it. That makes it a decision point, not a testing phase - it ends with a named person accepting a release, conditionally accepting it, or rejecting it.

What makes a cycle work is almost entirely preparation. Entry criteria that are enforced, so users are not doing QA's work. Scenarios written as business processes in business language. An environment and data that resemble reality closely enough for people to test their own cases. Protected time for participants who have day jobs. A defect route that separates defects from change requests. Exit criteria agreed before the cycle rather than negotiated during it.

And it should not start from scratch each time. Most UAT scenarios describe processes that outlive any single release, so they are worth keeping. QA Sphere holds UAT scenarios as versioned test cases, runs each cycle as a tracked test run with live progress and per-scenario history, and links what users find to your tracker through issue tracker integration - so the sign-off record is evidence rather than an email. See pricing or book a demo.