User Acceptance Testing (UAT): Process, Checklist, and Examples

Software can pass every functional test and still fail the people expected to use it.

An invoice may calculate correctly but follow the wrong approval route. A CRM may store every required field while making the sales process slower. A migrated account may appear complete but lack the historical data needed by customer support.

User acceptance testing, or UAT, is where these gaps become visible. It determines whether a solution supports the agreed business processes – not merely whether its individual functions work.

This guide explains how to plan and conduct UAT, choose participants, prepare realistic scenarios, classify findings, and reach an evidence-based acceptance decision. It also includes reusable templates for a UAT plan, test cases, and final sign-off.

What is user acceptance testing?

User acceptance testing is a structured evaluation in which business users or authorized representatives verify that a solution supports their needs, workflows, and acceptance criteria.

Microsoft defines UAT as a way for business stakeholders and end users to verify that deliverables meet their needs. That distinction matters. UAT is not simply another round of quality assurance performed by a different group of people.

Functional and system testing ask: does the software behave according to its specification?

UAT asks: does the delivered solution allow the business to perform the required work, under realistic conditions, well enough to be accepted?

A QA team may coordinate the process, prepare data, help create scenarios, and triage findings. The final acceptance decision, however, should belong to a stakeholder authorized to accept the solution and its remaining risks.

What UAT is not

Several activities are regularly labeled UAT even though they serve a different purpose.

UAT is not:

• a replacement for functional or regression testing;

• the first time the customer sees the product;

• a product demonstration;

• general employee training;

• exploratory testing performed only by QA;

• a beta program for gathering broad market feedback;

• testing directly in production without controls;

• approval based only on a percentage of passed test cases;

• a guarantee that no defects will appear after release.

UAT may identify technical defects, but finding bugs is not its only objective. It can also reveal missing requirements, unsuitable workflows, permission problems, incomplete data, training gaps, and operational constraints.

Why user acceptance testing matters

A requirement can be implemented accurately and still fail to solve the intended business problem.

Consider a purchasing system that requires two approvals for orders above $10,000. The approval logic may work exactly as documented. During UAT, however, the purchasing team may discover that the system does not support delegated approval when a manager is unavailable. The software is functioning as specified, but the real business process cannot be completed.

Effective UAT helps a team:

• validate end-to-end business workflows;

• confirm that real user roles and permissions are correct;

• verify migrated or representative data;

• expose differences between documented and actual processes;

• assess whether integrations produce the expected business outcome;

• identify training and documentation needs;

• record known limitations and residual risks;

• give decision-makers evidence for go-live approval;

• create an acceptance record for contractual or regulated projects.

A successful UAT cycle does not prove that a product is defect-free. It shows that representative users have completed the required business processes and that the authorized stakeholder understands the remaining risk.

UAT vs system testing, regression, beta testing, and OAT

UAT belongs to the broader category of acceptance testing, but not every acceptance activity is UAT.

The ISTQB Acceptance Testing syllabus covers user, contractual, regulatory, alpha, and beta acceptance testing. Operational acceptance testing has a separate focus: whether the organization can operate, support, secure, and recover the system.

UAT vs acceptance criteria

Acceptance criteria describe the conditions a requirement, story, or feature must satisfy. They should be defined before development and may be verified throughout implementation.

UAT is a broader business evaluation. It combines multiple requirements and acceptance criteria into realistic end-to-end workflows and supports a release or handover decision.

UAT vs acceptance testing in Agile

Agile teams often use executable acceptance tests or story tests as part of specification and development. The Agile Alliance describes an acceptance test as a formal example of software behavior, frequently connected to a user scenario.

These tests can provide valuable automated coverage, but they do not always replace formal UAT. A business stakeholder may still need to validate a complete release, migrated data, cross-department workflow, or operational change.

When should UAT happen?

UAT planning should begin much earlier than UAT execution.

The team should think about acceptance while it is:

• defining business requirements;

• writing acceptance criteria;

• modeling business processes;

• selecting integrations;

• planning migration;

• identifying user roles;

• estimating release activities.

Formal execution typically happens after the system has reached a stable state and before production deployment, handover, or a major rollout.

Common prerequisites include:

• a stable release candidate;

• completed system and integration testing;

• regression results available;

• no blockers that make business workflows impossible;

• a verified UAT environment;

• representative data;

• correctly configured user roles;

• available business participants.

UAT does not always have to wait until every minor defect has been resolved. Known issues can be documented and accepted if they do not invalidate the evaluation. The decision should depend on business impact rather than a blanket requirement that every defect be closed.

Does every project need a separate UAT cycle?

Every product needs some form of acceptance, but not every change requires a formal multi-week UAT phase.

The format should reflect the consequences of accepting the wrong behavior.

Who performs UAT?

The best UAT participants are not necessarily the most technically experienced people. They are the people who understand how the business process actually works.

Depending on the product, participants may include:

• business owners;

• product owners;

• subject-matter experts;

• end-user representatives;

• customer representatives;

• business analysts;

• implementation consultants;

• compliance specialists;

• UAT coordinators;

• QA engineers.

Choose participants according to the roles and workflows being evaluated. If a process crosses finance, operations, customer support, and management approval, testing it only with one department leaves important gaps.

The business approver should also be identified before execution begins. This person needs the authority to accept residual risk, impose conditions, postpone the release, or reject the delivered solution.

Typical UAT responsibilities

This distribution is only an example. In a smaller team, one person may cover several roles. The important point is that responsibility for the acceptance decision remains clear.

UAT entry criteria

Entry criteria prevent a team from inviting busy business users into a testing process that is not ready.

Before UAT begins, confirm that:

• UAT objectives and scope have been approved;

• business requirements and acceptance criteria are available;

• the intended release candidate has been deployed;

• system, integration, and regression testing have reached the agreed completion level;

• no unresolved blocker prevents execution of a critical workflow;

• the UAT environment has been verified;

• integrations required for testing are available;

• user roles and permissions have been configured;

• representative or migrated data is ready;

• sensitive data is handled according to privacy and security requirements;

• UAT scenarios have been reviewed;

• participants are selected and available;

• users understand the process and reporting tool;

• the defect and finding workflow is agreed;

• support contacts and triage times are published.

Entry criteria should protect the value of UAT without becoming an excuse to wait for a theoretically perfect build.

How to conduct user acceptance testing

1. Define the business objective

Begin with the outcome the organization expects – not a list of screens or features.

For example:

Feature-focused objective:
“Test the new invoice module.”

Business-focused objective:
“Confirm that employees, finance reviewers, and managers can submit, validate, approve, reject, and export invoices according to the company’s purchasing policy.”

The second objective immediately suggests relevant roles, workflows, data, integrations, and exceptions.

2. Define the scope

List the business processes, user roles, integrations, locations, and data states included in UAT.

Also record exclusions. If mobile approval, historical records, or a regional tax flow will not be evaluated, that decision should be visible before sign-off.

3. Agree on acceptance criteria

Acceptance criteria should be observable and testable.

Weak criterion: The invoice workflow should work correctly.

Better criterion: A finance manager can approve or reject an invoice above $10,000, and the system records the decision, timestamp, comment, and approver identity before updating the ERP.

Good acceptance criteria describe meaningful behavior without prescribing unnecessary implementation details.

4. Select representative users

Include people who understand normal workflows as well as exceptions.

A process may behave differently for:

• a new employee;

• a manager with delegated authority;

• a regional finance user;

• an administrator;

• a customer support representative;

• a user working with migrated records.

Selecting only senior stakeholders can produce an unrealistic evaluation. They may understand the desired outcome but not perform the daily work.

5. Prepare the UAT plan

The plan should define:

• project and release;

• objectives;

• scope;

• participants;

• roles;

• schedule;

• environment;

• test data;

• scenarios;

• entry and exit criteria;

• finding classification;

• reporting;

• sign-off process.

For guidance on creating the broader testing plan, see our software test plan guide.

6. Prepare the environment, access, and data

A UAT environment should resemble production closely enough to provide credible evidence. That does not mean it must be an exact copy.

Verify:

• the correct release version;

• feature flags;

• user permissions;

• integrations;

• notifications;

• reporting;

• migrated records;

• time zones and locales;

• realistic business data;

• audit logging.

Avoid using production personal or financial data unless the access, masking, legal basis, and controls are appropriate. Synthetic or anonymized data may be safer, but it still needs to represent meaningful business conditions.

7. Create business-oriented scenarios

UAT scenarios should be organized around user goals.

A QA functional test may verify that an approval button is enabled under specific conditions. A UAT scenario should verify that the complete approval process produces the expected business outcome.

Keep instructions detailed enough for consistent execution but not so prescriptive that testers stop evaluating the process.

8. Conduct a dry run

Before inviting business users, verify that:

• accounts work;

• test data is present;

• links are correct;

• required integrations respond;

• instructions are understandable;

• findings can be submitted;

• the support team can access evidence.

A short dry run can prevent an entire UAT session from being lost to permissions or environment problems.

9. Brief the participants

Explain:

• what UAT is intended to validate;

• what is in and out of scope;

• how to execute scenarios;

• how to record actual results;

• how to submit evidence;

• whom to contact when blocked;

• how findings will be classified;

• what happens after a failed scenario.

Training should explain the UAT process. It should not become the first complete training session for the new system.

10. Execute and monitor UAT

Track progress by business process, role, and risk – not just by total test count.

During execution, provide support without steering users toward a preferred result. If a participant finds a different but valid way to perform the task, that information may be valuable.

Record results as:

• Pass;

• Fail;

• Blocked;

• Not Run.

“Blocked” should be separate from “Fail.” A scenario blocked by an unavailable integration tells the team something different from a workflow that produced an incorrect result.

11. Triage findings

Not every issue raised during UAT is a software defect. Classify findings consistently and record their business impact.

A disagreement over classification should not prevent the team from recording the effect on the business process.

12. Fix and retest

Not every finding needs to be resolved before approval.

The team should decide whether to:

• fix it immediately;

• retest it in the current cycle;

• accept the risk;

• provide a workaround;

• remove the affected scope from the release;

• schedule the change for a later release;

• extend UAT.

Prioritize by business impact, not only technical severity.

13. Prepare the UAT report

The report should allow a decision-maker to understand:

• what was tested;

• which roles participated;

• which critical processes were covered;

• what passed, failed, or remained blocked;

• which issues remain open;

• what risks or limitations remain;

• what conditions are attached to approval.

A pass-rate percentage without this context is weak evidence.

14. Obtain a documented decision

The outcome does not have to be a simple pass or fail.

Possible decisions include:

• accepted;

• accepted with conditions;

• rejected;

• UAT extended;

• release scope reduced;

• rollout limited to a pilot group.

The approver, decision date, conditions, and accepted risks should be recorded.

Copy-ready UAT plan template

Project information

Project or release:
UAT owner:
Business approver:
UAT period:
Environment and build:
Document version:

Objectives

Describe what business outcomes UAT should validate.

In scope

List included processes, roles, integrations, configurations, and data.

Out of scope

List exclusions and the reason for each one.

Critical business processes

Prioritize the workflows that must succeed before approval.

Participants and responsibilities

List business testers, subject-matter experts, coordinators, support contacts, and approvers.

Entry criteria

State the conditions required to begin UAT.

Exit criteria

State the evidence required to complete UAT and reach an acceptance decision.

Environment and data

Describe the environment, integrations, accounts, permissions, datasets, and privacy controls.

Scenarios

Link each scenario to a business requirement, process, risk, or acceptance criterion.

Finding management

Define categories, business-impact levels, submission requirements, and triage frequency.

Schedule

Include environment validation, dry run, execution, triage, retesting, reporting, and sign-off.

Reporting

Specify the dashboard, daily updates, final report, and escalation path.

Risks and constraints

Record availability, data, environment, dependency, and timing risks.

Sign-off process

Name the authorized approver and describe the possible decisions.

UAT test case template

A practical UAT test case can use the following fields:

For more detailed test case formats, see our guide to test case templates and examples.

Completed UAT example: Invoice approval

Test case information

Test case ID: UAT-INV-014
Business process: Invoice approval
User role: Finance manager
Business objective: Approve a high-value invoice and send it to the ERP for payment
Related requirement: INV-23
Environment: UAT build 4.7
Priority: Critical

Preconditions

• The employee has submitted an invoice for $14,500.

• The finance reviewer has validated the invoice.

• The invoice requires manager approval because it exceeds $10,000.

• The finance manager has the appropriate approval limit.

• The ERP sandbox is available.

Test data

• Supplier: Northwind Office Supplies

• Invoice number: NW-49018

• Amount: $14,500

• Cost center: Operations

• Submitter: Employee A

• Approver: Finance Manager B

Scenario

Expected outcome

• The invoice appears in the manager’s approval queue.

• The manager can review the supporting information.

• Approval requires a comment.

• The status changes to Approved.

• The audit history records the approver, date, time, and comment.

• The invoice is transferred to the ERP with the correct amount and cost center.

• The submitter receives a confirmation.

Actual outcome

The approval was recorded, but the invoice was transferred to the ERP without the cost center.

Result

Fail

Finding

Finding ID: UAT-87
Classification: Defect
Business impact: High. The invoice cannot be posted correctly without manual correction in the ERP.

Required action

Correct the integration mapping and retest the approval and export scenarios before sign-off.

UAT exit criteria

Before closing UAT, confirm that:

• all critical business processes were executed;

• required business roles participated;

• critical requirements and risks were covered;

• no unresolved blocker defects remain;

• high-impact findings were fixed or formally accepted;

• failed critical scenarios were retested where required;

• known limitations were documented;

• workarounds were evaluated;

• training and operational implications were reviewed;

• the final report was prepared;

• the authorized business owner recorded a decision.

A universal requirement that 100% of tests must pass can be counterproductive. A blocked low-risk scenario should not necessarily outweigh a documented, accepted release decision. Conversely, a 98% pass rate means little if the failed scenario prevents a critical payment or compliance process.

UAT sign-off template

Project information

Project or release:
Environment and build:
UAT period:
UAT coordinator:
Business owner:
Decision date:

Execution summary

Total scenarios:
Passed:
Failed:
Blocked:
Not executed:
Critical business processes covered:
Open findings by impact:

Known limitations and residual risks

List every material limitation that will remain after approval.

Conditions for approval

Record required fixes, workarounds, monitoring, training, documentation, or follow-up activities.

Deferred changes

List accepted change requests that are outside the current release.

Decision

• Accepted

• Accepted with conditions

• Rejected

• UAT extended

• Release scope reduced

Approval

Approver:
Role:
Date:
Comments:

The sign-off confirms an informed business decision. It is not a declaration that the software contains no defects.

UAT in Agile and continuous delivery

Agile delivery should move acceptance discussions earlier, not eliminate them.

During backlog refinement, business, development, and QA representatives can:

• clarify user goals;

• define acceptance criteria;

• identify examples and exceptions;

• discuss test data;

• expose ambiguous business rules;

• agree on evidence.

Business stakeholders can review increments throughout development. Formal UAT may then focus on release-level workflows, integrations, migration, roles, and readiness rather than rediscovering basic requirement problems at the end.

For continuous delivery products, teams can use:

• ongoing acceptance by the product owner;

• automated acceptance checks;

• feature flags;

• pilot groups;

• staged rollouts;

• targeted UAT for high-risk changes;

• documented approval workflows for regulated releases.

A release containing a pricing change or new financial approval process may require explicit UAT. A small text correction may not.

Can UAT be automated?

Parts of the UAT process can and should be automated where it reduces repetitive work.

Automation can support:

• account creation;

• test data preparation;

• environment health checks;

• regression prerequisites;

• repetitive setup;

• evidence collection;

• requirement traceability;

• notifications;

• progress reporting;

• selected acceptance checks.

Formal business acceptance still requires human responsibility. A script cannot independently decide whether a workflow is practical, whether a workaround is acceptable, or whether the business should assume a residual risk.

Automated acceptance tests and UAT are related but not interchangeable. Automated checks verify previously defined expectations. UAT allows business representatives to evaluate whether those expectations describe an acceptable solution.

Useful UAT metrics

Track metrics that support decisions:

• scenario execution progress;

• critical business-process coverage;

• pass, fail, blocked, and not-run status;

• findings by business impact;

• finding age;

• retest completion;

• requirement coverage;

• findings by category;

• participation by business role;

• accepted residual risks;

• time from finding submission to classification;

• time from finding to business decision.

A high defect count does not necessarily mean UAT was poorly conducted. It may indicate that UAT exposed important gaps. More useful questions are whether critical issues were found, understood, and resolved before acceptance.

UAT tools

The best tool is one the business participants can access and understand.

Typical categories include:

• Planning and documentation: Confluence, Notion, and Google Docs

• Test management: TestRail, Xray, Zephyr, and Azure Test Plans

• Issue tracking: Jira and Azure DevOps

• Feedback capture: Usersnap, Userback, and screen-recording tools

• Lightweight UAT: Google Sheets or structured project boards

• Reporting: dashboards within the existing delivery ecosystem

Microsoft’s Azure Test Plans documentation illustrates how teams can organize tests around requirements, assign configurations and testers, and continue execution until exit criteria are met.

A sophisticated platform is not always necessary. For a small release with five business users, a well-structured spreadsheet may be more effective than a tool requiring extensive training and permissions.

Common UAT mistakes

1. Planning UAT at the end

If participants, data, criteria, and environments are considered only after development finishes, UAT becomes rushed and superficial.

2. Using QA regression cases as UAT scenarios

QA cases often focus on detailed functional behavior. UAT should reflect business goals and end-to-end work.

3. Selecting participants only because they are available

Testers must understand the roles and processes they represent.

4. Treating UAT as training

Users should receive enough preparation to test the process. Otherwise, the findings become dominated by unfamiliarity with the system.

5. Using unrealistic data

Empty accounts and simplified records rarely expose the problems found in actual workflows, migrations, permissions, and integrations.

6. Inviting users to an unstable build

Business participants should not spend their limited time rediscovering blockers already detectable through functional testing.

7. Allowing QA to approve on behalf of the business

QA can recommend, report, and facilitate. Business acceptance requires business authority.

8. Calling every request a defect

Some findings are new requirements, training gaps, documentation problems, or change requests. Classification keeps scope and release decisions manageable.

9. Calling every unexpected result a change request

If delivered behavior contradicts an approved requirement or prevents an agreed workflow, it may be a defect rather than new scope.

10. Relying only on the pass rate

A percentage does not describe which workflows failed, why they failed, or whether the remaining risk is acceptable.

11. Rushing sign-off to preserve a fixed release date

A signature obtained without time to understand open risks provides little protection.

UAT checklist

Before UAT

• Objectives and scope are approved.

• A business owner and approver are named.

• Representative testers are available.

• Acceptance criteria are clear.

• Critical workflows are prioritized.

• The release candidate is stable.

• The UAT environment is verified.

• Data, integrations, accounts, and permissions are ready.

• Scenarios are reviewed.

• Entry criteria are met.

• Reporting and triage processes are agreed.

During UAT

• Progress is tracked by process and business role.

• Blockers are escalated quickly.

• Actual outcomes and evidence are recorded.

• Findings are classified.

• Business impact is documented.

• Requirement changes are controlled.

• Critical failed scenarios are retested.

• Known risks remain visible.

Before sign-off

• Critical processes have been evaluated.

• Unresolved findings have been reviewed.

• Residual risks have owners.

• Workarounds are documented.

• Training and support implications are understood.

• The final report is available.

• Approval conditions are explicit.

• The decision is recorded by an authorized stakeholder.

Turning UAT into a meaningful release decision

UAT works when it is treated as a business decision process rather than a final testing ceremony.

Start planning acceptance while requirements are still being discussed. Select people who know the real workflows. Give them a stable environment, realistic data, and business-oriented scenarios. Classify their findings fairly, make the remaining risks visible, and ensure the final decision belongs to someone authorized to make it.

If you need support preparing scenarios, coordinating participants, managing UAT findings, or turning the results into a clear go-live recommendation, DeviQA provides dedicated user acceptance testing services.

Ready to rethink your QA?

Schedule a call

Frequently asked questions

Who performs user acceptance testing?

UAT is normally performed by business users, customer representatives, product owners, or subject-matter experts who understand the real process. QA can prepare and facilitate testing, but the final acceptance decision should be owned by an authorized business stakeholder.

Is UAT performed by QA?

QA may coordinate UAT, help design scenarios, prepare data, support participants, and triage findings. However, testing performed only by the internal QA team does not provide independent business acceptance unless QA is explicitly acting under the authority of the customer or business owner.

When should UAT start?

Planning should begin during requirements definition. Formal execution usually takes place on a stable release candidate after sufficient system, integration, and regression testing and before production deployment or handover.

What is the difference between UAT and system testing?

System testing verifies that the complete system meets specified technical and functional requirements. UAT determines whether the delivered solution supports the required business processes and can be accepted for use.

What is the difference between UAT and beta testing?

UAT is a structured acceptance process based on defined business requirements and approval authority. Beta testing collects feedback from a selected or open external audience under broader real-world conditions.

What is the difference between UAT and acceptance criteria?

Acceptance criteria define the conditions an individual requirement or feature must meet. UAT evaluates broader business processes, often combining several features, integrations, roles, and criteria into realistic workflows.

Does every project need UAT?

Not every change requires a separate formal UAT cycle. The decision depends on business risk, contractual obligations, regulatory requirements, workflow complexity, and how directly stakeholders have already participated in acceptance.

Can UAT be automated?

Setup, data creation, evidence collection, reporting, and selected acceptance checks can be automated. The final assessment of business fitness and acceptance of residual risk still require accountable human stakeholders.

What should a UAT test case include?

A UAT test case should contain the business objective, user role, preconditions, realistic data, scenario, expected business outcome, actual result, status, business impact, evidence, and a link to any reported finding.

What happens if UAT fails?

The team may fix and retest the issue, extend UAT, accept a documented risk, provide a workaround, reduce release scope, postpone deployment, or reject the delivery. The response should reflect business impact.

Can a release be approved with failed UAT tests?

Yes, if the failures do not create unacceptable risk and an authorized stakeholder understands and formally accepts them. Critical workflows or blocker defects will normally prevent approval, but a universal 100% pass requirement is not always necessary.

Who signs off UAT?

The sign-off should come from a business owner, customer representative, product owner, or another stakeholder authorized to accept the solution and its residual risks.

About the author

Dmitry Reznik

Chief Technology Officer

Dmitry Reznik is the Chief Technology Officer and co-founder at DeviQA, bringing deep technical expertise across software architecture, implementation, and long-term system operation.