User Acceptance Testing (UAT): Meaning, Process, Examples

User acceptance testing (UAT) is the test level where intended users check whether a finished system meets the business requirements they signed off on, and decide whether to accept it. The ISTQB Certified Tester Foundation Level syllabus lists UAT as one of six forms of acceptance testing, alongside operational, contractual, regulatory, alpha, and beta testing.^[1] This guide explains what UAT means, why teams run it, who performs it, the types of acceptance testing, a 7-step UAT process, acceptance criteria, worked test cases, tools, metrics, and how UAT differs from beta and system testing.

What is User Acceptance Testing?

UAT stands for user acceptance testing. The ISTQB glossary defines it as a type of acceptance testing performed to determine if intended users accept the system.^[2] UAT runs after system, functional, and regression testing, and it answers a different question than any of them: not whether the software works, but whether it does the job the business asked for.

That distinction decides who runs UAT and what counts as a defect. System testing verifies the specification. UAT verifies the intent behind the specification, so the people running it are the ones who own the business process, and a working feature that solves the wrong problem still fails.

The UAT environment must mirror production in data shape, integrations, and access controls. Without that, UAT scenarios miss the defects that only appear under production-like conditions, and the sign-off certifies an environment nobody will ever use.

Why Perform User Acceptance Testing?

UAT catches requirements defects that every earlier test level is blind to. Unit, integration, and system tests all check the software against the written specification, so a requirement captured wrongly passes all three and still fails the user.

Finding a requirements defect at UAT is already late, and finding it after release is later still. The cost climbs because the fix is no longer a code change: it means re-opening the requirement, re-testing the dependent workflows, retraining the users who learned the wrong process, and correcting whatever bad data the wrong behavior produced in the meantime. Running UAT properly buys four things:

• Requirements validation: Business users confirm the delivered workflow matches the process they actually run, not the process the specification described.
• Release risk reduction: Defects found in UAT are fixed before customers meet them, which avoids the emergency patch and the support-ticket spike that follow a bad release.
• Documented sign-off: UAT produces a dated acceptance record naming who approved what, which is the artifact auditors and contract disputes rely on.
• Upstream quality signal: The UAT defect count tells you how well the earlier test levels are working, because a clean UAT is evidence that system testing did its job.

Who Performs User Acceptance Testing?

The client or end users of the software conduct UAT. That means the people who bought the product or commissioned it, drawn from the organizational groups whose daily work the software changes, so every affected user role is represented.

In practice the job title matters less than a different test: who designed, reviewed, and approved the test cases. A QA engineer executing scenarios that business owners wrote and signed is doing UAT. A business owner executing scenarios QA wrote is doing a second round of system testing with a friendlier audience.

One recruitment rule is worth applying deliberately. Choose testers who were not involved in designing the software, because the people who specified a workflow cannot see the assumptions they built into it.

Types of User Acceptance Testing

Acceptance testing has six recognized forms, and UAT is one of them rather than an umbrella term for the rest. The ISTQB Foundation Level syllabus names user acceptance testing, operational acceptance testing, contractual acceptance testing, regulatory acceptance testing, alpha testing, and beta testing as the main forms.^[3] What separates them is who accepts the system and where the testing happens, not how deep the testing goes.

Two further terms appear constantly in practice without appearing in that syllabus list: prototype testing and factory acceptance testing. Both are covered below because teams genuinely run them, but they are industry practice rather than ISTQB vocabulary. The ISTQB glossary carries no entry for factory acceptance testing or site acceptance testing at all, and contractual acceptance testing, though the syllabus names it, has no standalone glossary definition. Where a term has no standard definition behind it, your contract is what defines it.

Alpha testing

Alpha testing is acceptance testing performed in the developer's own test environment by roles outside the development organization.^[4] The development team fixes what alpha testing finds before the build reaches any external audience.

Beta testing

Beta testing is acceptance testing performed at a site external to the developer's test environment, by roles outside the development organization.^[5] Location is the discriminator between alpha and beta, not rigor: prospective customers run beta builds on their own hardware, networks, and data, which surfaces environment-specific failures a controlled lab never reproduces.

Operational acceptance testing

Operational acceptance testing determines whether the organization responsible for operating the system can accept it.^[6] The acceptor is the operations or SRE team, not the business user, and that changes the entire test set: backup and restore, failover and disaster recovery, patching, monitoring and alerting, and access control.

Calling UAT the last gate before production skips this gate. A system can pass every business scenario and still be unrunnable, because nobody proved the restore path works. Teams that run acceptance testing as a single business-user event tend to discover that on the first bad night in production.

Prototype testing

Prototype testing puts an early build or clickable mock in front of a focus group to validate interface clarity before the final version exists, so design changes land while they are still cheap.

Contract and regulation acceptance testing

Contract acceptance testing validates the product against the criteria written into the contract or service level agreement. Regulatory acceptance testing determines the compliance of the test object against the rules it must satisfy,^[7] covering data protection law and industry-specific regulation. Both answer to an external arbiter, so their evidence has to survive an audit rather than a release meeting.

Factory acceptance testing

Factory acceptance testing (FAT) validates software and hardware together inside the supplier's facility before anything ships. FAT is common in industrial, medical, and embedded systems, where it catches integration faults while the whole assembly is still on the supplier's bench.

How to Perform User Acceptance Testing?

The UAT process runs in seven steps, from business requirement analysis through to results recording. Each step produces an artifact the next one consumes, so skipping one leaves the following step guessing.

• Business requirement analysis

Derive the scenarios from business use cases, process flow diagrams, and the system requirements specification (SRS). The output is a list of real tasks users perform, not a list of features the build contains.

• Test plan creation

The plan documents entry and exit criteria, the test case approach, the scenarios, and the timeline. It is the artifact that tells everyone when UAT may start and when it is finished.

• Test scenario identification

Prioritize the business processes that carry money, compliance, or customer commitments. Cover those end to end before spending time on lower-risk paths.

• Creation of test cases

Write each case in business language with its acceptance criterion attached, and give testers the data flow they need to interpret results. See how to write a UAT test script for the step-level format, and test coverage for deciding what the case set must reach.

• Test data preparation

Build the data set the scenarios need before execution starts. Use production-like synthetic data that matches real volumes, edge cases, and character sets, and never copy live customer records into UAT. Real data breaks privacy rules and also narrows coverage, because your own account history contains only the paths you personally take.

• Running the test cases

Testers execute each scenario, mark it pass or fail against its acceptance criterion, and log every failure with reproduction steps, environment details, and a screenshot. Failed tests are fixed and re-run, not argued about. Test management tools hold the execution status and the defect trail in one place so the sign-off has evidence behind it.

• Results recording

Record the outcome and issue the acceptance decision. That means confirming no critical defect is still open, checking each business process against its criterion, capturing stakeholder feedback, and sending the dated sign-off that names who accepted what.

The deliverables from this step are the UAT scenarios, the test plan, the executed test cases, the defect log, and the sign-off record. Those five artifacts are what an auditor or a contract dispute asks for later.

What Are UAT Acceptance Criteria?

Acceptance criteria are the conditions a work product must satisfy to be accepted by the stakeholders.^[8] In UAT they are the pass or fail rule for every scenario, and they are written and agreed before testing starts, not negotiated once a defect is in dispute.

A criterion is testable when two different testers reach the same verdict from it. That is the whole bar, and it is the one most criteria fail:

• Not testable: The checkout page loads quickly. Two testers will disagree, because neither has a threshold.
• Testable: The checkout page renders the payment form within 3 seconds on a 4G connection. The verdict is identical for anyone who runs it.
• Not testable: Invalid card details are handled gracefully. Graceful is an opinion.
• Testable: A declined card keeps the user on the payment step, shows the issuer decline reason, and preserves the cart contents.

Entry criteria and exit criteria bracket the UAT window. Entry criteria state what must be true before UAT starts: system testing complete, the UAT environment provisioned with test data, no open critical defects carried over, and the test scenarios signed off. Exit criteria state what must be true before sign-off, and they rest on four numbers: scenario pass rate, open defects by severity, defect density, and acceptance criteria coverage.

Who writes the criteria is a scope-control decision, not an administrative one. When business users derive their own scenarios from requirements they already approved, UAT stays a check against the agreed scope. When testers arrive without written criteria, UAT turns into a feature-request channel, and unrequested functionality gets logged as defects.

What Do UAT Test Cases Look Like?

A UAT test case describes a complete business task in the user's own language, with the data to use and the outcome that counts as acceptance. It never names a CSS selector, an API endpoint, or a database table, because the person running it is testing the business process rather than the implementation.

These illustrative examples cover a retail checkout release. Each one maps a scenario to the acceptance criterion that decides it:

Notice what UAT-04 and UAT-05 have in common. Both cross a system boundary, into inventory and into finance, and both are the kind of case that passes in isolation and fails in an integrated environment. Those are the scenarios worth spending UAT time on, because the single-screen happy paths were already covered by system testing.

User Acceptance Testing Tools

UAT tooling has to serve non-technical testers, so the selection criteria differ from an automation stack. What matters is how easily a business user can record a defect with evidence attached, and whether the team can put testers on the device and browser the customer actually uses.

TestMu AI

A recurring UAT constraint is device access: business testers sign off on whatever laptop they were issued, so defects that only appear on a customer's phone reach production unseen. TestMu AI is a cloud testing platform that gives testers a remote test lab reachable from a browser, with 10,000+ real Android and iOS devices for mobile app testing and 3,000+ real browser and OS combinations for web. Sessions record video and console logs, so a UAT defect report carries reproduction evidence instead of a description.

Tricentis Tosca

Tricentis Tosca is a model-based tool that builds automated tests from business processes rather than from scripts. It covers API testing, GUI testing, mobile testing, and data-driven testing, and the model-based approach is aimed at teams whose UAT scenarios map to documented process flows.

TestComplete

TestComplete is an automated testing environment that supports Windows, .NET, WPF, Visual C++, Visual Basic, Delphi, C++Builder, Java, and web applications and services. The breadth of desktop technology support makes it a fit where the system under acceptance is a thick client rather than a web app.

User Acceptance Testing Design Template

A UAT design template documents the plan for a given release so the same structure is reused every cycle. A ready-made UAT test case template with worked examples covers the case-level format; the sections below are what the plan document itself needs:

• Project name: The project and the software version under acceptance.
• Testing objectives: What this cycle must prove before sign-off.
• Test items: The features and processes in scope, and what is explicitly out.
• Environment requirements: The hardware, browsers, devices, and data set testers need.
• Entry criteria: The conditions that must hold before testing may begin.
• UAT team: The named testers and the named approver, by role.
• Exit criteria: The thresholds that signify testing is complete.
• Change log: Amendments made to the plan mid-cycle, dated.

Keep the template in business language throughout. A UAT document written in QA vocabulary gets skimmed by the people who are supposed to sign it, and a signature on a document nobody read does not represent a real acceptance decision.

How Do You Measure UAT?

Measure UAT on four numbers: scenario pass rate, open defects by severity, defect density, and acceptance criteria coverage. Together they answer the only question sign-off asks, which is whether the remaining risk is acceptable to the people who own the process.

• Scenario pass rate: Executed scenarios that passed, divided by scenarios planned. Computing it against executed rather than planned scenarios hides the ones nobody got to.
• Open defects by severity: Count critical and high separately from cosmetic. A single open critical defect blocks sign-off regardless of how good the pass rate looks.
• UAT defect density: Defects found per scenario executed. This number measures the earlier test levels, not UAT.
• Acceptance criteria coverage: Criteria with at least one executed scenario, divided by criteria agreed. Anything below 100% means part of the signed scope was never checked.

Read defect density as an upstream signal. A UAT cycle that surfaces dozens of functional defects shows system testing let them through. Extending the UAT window treats the symptom. The response is to fix the earlier stage, because UAT is sized to confirm business fit rather than to act as a second QA pass.

Exit criteria turn those numbers into a decision. A workable set is: every agreed acceptance criterion has an executed scenario, zero open critical or high defects, all remaining defects triaged with an owner and a target release, and the named business approver has signed. Fix the thresholds before UAT starts, for the same reason acceptance criteria are written early.

One scaling caveat applies to multi-tenant products. UAT validates a system against a specific customer's requirements, so 50 enterprise customers with 50 configured workflows can mean 50 separate acceptance cycles rather than one. That arithmetic, not the testing effort itself, is what makes outsourced UAT hard to buy as a single service.

Simplify User Acceptance Testing on Cloud

Business testers rarely have the customer's device on their desk, so acceptance happens on a corporate laptop and mobile-only defects survive to production. Running UAT sessions on a cloud device lab removes that gap without shipping hardware to anyone. The steps below start a real-device browser session on TestMu AI.

Step 1: Select Real Device from the left menu of the dashboard to access Browser Testing on mobile.

Step 2: Under the Real Device menu, click on Browser Testing. On the right side of the screen, you can provide the URL, and select the browser, device, device type, and OS version.

Step 3: Click the Start button and wait for the device to launch based on the configuration.

Once the device is launched, you can use various options to help you perform testing effectively. The real time browser testing documentation covers the session controls in detail.

Challenges in User Acceptance Testing

Most UAT problems are scheduling and staffing problems, not testing problems. The business owns the testers, the developers own the fix window, and neither owns the calendar, so UAT gets compressed from both ends. The cost of that compression is asymmetric: a requirement rejected in UAT is rework, unscheduled change, and occasionally a cancelled project, which is why acceptance checkpoints belong early enough that rejection is still affordable.

• Lack of communication

Business testers, analysts, and developers work from different vocabularies, so a defect described as "the report looks wrong" reaches a developer with nothing actionable in it. Route every UAT defect through one tracker with mandatory reproduction steps, environment, and a screenshot.

• New stakeholder requirements

Testers who meet the system for the first time raise features nobody specified, and those arrive logged as defects. Triage them against the signed acceptance criteria: anything outside that scope becomes a backlog item for a later release, not a blocker for this one.

• Compressed scheduling

UAT sits last in the sequence, so every upstream delay eats its window while the release date holds. Plan the UAT slot during requirements and risk analysis, and protect it as a fixed duration rather than a buffer.

Putting UAT inside the definition of done has the same effect from the other direction, because it makes story completion depend on people outside the delivery team. Teams that hit this usually decouple with feature flags and let the business accept on its own schedule. The test strategy is where that decision belongs, alongside risk analysis and management strategies.

• Providing personal opinions

Preference feedback arrives mixed in with genuine defects, and dismissing it damages the relationship you need for the next cycle. Ask what task the tester was trying to finish. That reframes a colour complaint into either a usability defect with a criterion behind it, or a backlog item.

Best Practices for User Acceptance Testing

Five practices separate a UAT cycle that produces a decision from one that produces a discussion:

• Identify and understand your target audience

Map the user roles the release touches, then recruit a tester for each one. A finance approver and a warehouse operator hit different failure modes in the same order-management release, so a tester pool drawn from one department certifies one slice of the system. Keep the development team out of the tester pool entirely.

• Develop the test plan

The plan names the objectives, the scenarios, the entry and exit criteria, and the schedule. Write it so a tester who has never seen the system can follow it unaided, because that is the actual reading level of your audience.

• Standardize bug reporting

Require reproduction steps, environment details, and a screenshot or screen recording on every report. Session recording removes the argument entirely, because the developer watches what the tester did instead of reconstructing it.

• Define your acceptance criteria correctly

Agree the criteria before testing starts, phrase them in business language, and make each one score pass or fail identically for two different testers. Criteria negotiated after a defect is raised no longer decide the outcome; they argue it.

• Observe how your customers react to visual aspects

Ask open-ended questions about layout, visual hierarchy, and color rather than asking whether the design looks good. Visual defects that testers notice but cannot articulate show up as hesitation, so watch where they pause. Automated smart visual UI testing catches the pixel-level regressions across browsers separately, which keeps the human session focused on comprehension instead of rendering bugs.

Note: Run UAT sessions on 3,000+ real browser and OS combinations with TestMu AI. Try it free

User Acceptance Testing vs. Beta Testing

User Acceptance Testing (UAT) and beta testing are distinct yet complementary stages within the software development life cycle. Explore those differences from the table below.

User Acceptance Testing Vs. System Testing

System testing checks the integrated system against its specification. UAT checks the same system against the business intent behind that specification, which is why the two differ on who runs them and what counts as a failure.

Sources and References Used

• [1] Certified Tester Foundation Level Syllabus v4.0.1, Section 2.2.1 Test Levels - ISTQB (September 2024)
• [2] User Acceptance Testing - ISTQB Glossary
• [3] Certified Tester Foundation Level Syllabus v4.0, Section 2.2.1 Test Levels - ISTQB, GASQ mirror (April 2023)
• [4] Alpha Testing - ISTQB Glossary
• [5] Beta Testing - ISTQB Glossary
• [6] Operational Acceptance Testing - ISTQB Glossary
• [7] Regulatory Acceptance Testing - ISTQB Glossary
• [8] Acceptance Criteria - ISTQB Glossary