A Complete Guide on User Acceptance Testing (UAT)

User acceptance testing (UAT) is performed by intended users or authorised business representatives to determine whether software supports real user needs and business processes well enough to be accepted for use.

UAT is not an additional round of general QA. Its purpose is to validate business fitness: can the people receiving the system complete the work it was built to support, using the correct rules, roles, data, and outcomes?

This guide explains how to prepare, execute, and close UAT without turning business users into software testers.

What Is User Acceptance Testing?

User acceptance testing is the process in which intended users or authorised business representatives validate that a system is fit for its intended use before it is accepted or released.

Think of UAT as the point where the conversation shifts from “Was the software built according to its specification?” to “Can our people rely on it to do their work?” That distinction is important because a technically correct feature can still misunderstand the workflow it was meant to support.

For example, a payroll user does not need to verify every internal calculation method or API response. The user needs evidence that they can:

• Prepare the correct payroll period
• Review exceptions
• Obtain the required approval
• Generate accurate payment and reporting outputs
• Restrict sensitive data to authorised roles
• Recover appropriately from a rejected or incomplete process

The ISTQB glossary defines UAT as a type of acceptance testing performed to determine whether intended users accept the system.

What UAT Is and What It Is Not

UAT is:

• Validation by intended users or their representatives
• Based on user needs, business processes, and acceptance criteria
• Focused on end-to-end tasks and outcomes
• Performed in a realistic or simulated operational environment
• Evidence for a business acceptance decision

UAT is not:

• A replacement for functional, integration, system, security, or performance testing
• An opportunity to ask business users to find ordinary bugs
• A product demonstration in which users only watch
• Training disguised as testing
• Unstructured feedback without expected results
• Automatic approval because a deadline has arrived

UAT may reveal functional defects, but finding basic defects is not its main purpose. If users cannot begin their workflows because the system is unstable, the product entered UAT too early.

UAT vs. Acceptance Testing

Now that the purpose is clear, it helps to place UAT within the wider testing process. The term is often used loosely, which can cause teams to assign the wrong people or evidence to the final approval.

Acceptance testing is the broader test level. UAT is one form within it.

The current ISTQB Foundation Level syllabus identifies user, operational, contractual, regulatory, alpha, and beta acceptance testing as the main forms.

Alpha, beta, operational, contractual, and regulatory acceptance testing should not all be labelled “types of UAT.” A project may conduct several forms alongside UAT, but their owners, evidence, and approval rules differ.

UAT vs. System Testing

The next common source of confusion is the boundary between UAT and system testing. Both may exercise the same journey, but they do so for different reasons and from different perspectives.

System testing should establish that the product is stable enough for UAT. Passing system testing does not guarantee user acceptance because the implemented system can still misunderstand the business process.

Why UAT Matters

UAT provides evidence that the delivered product:

• Supports the intended day-to-day processes
• Applies business rules correctly from the user’s perspective
• Gives each role the correct access and actions
• Produces useful records, reports, notifications, and outputs
• Handles important exceptions in an acceptable way
• Uses terminology and workflow steps users understand
• Satisfies the agreed user-level acceptance criteria
• Is ready for a documented go/no-go decision

It can reveal requirement gaps that conventional testing cannot resolve alone. A report can be technically accurate against its specification yet unusable because the business requires a different grouping, cut-off rule, or approval view that was never documented.

When Should UAT Be Performed?

This value depends heavily on timing. Start too early and users spend the session rediscovering ordinary defects; start too late and there may be no realistic time to respond to valid business feedback.

Formal UAT usually occurs after relevant system testing and before go-live, client handover, or business adoption.

In iterative delivery, UAT may also happen:

• At the end of a feature or sprint
• Before a controlled release
• During a release-candidate review
• Before migrating users or data
• Before replacing an existing workflow
• Before enabling a major feature flag

The execution occurs late enough to use stable software, but UAT planning starts early. User representatives should contribute examples and acceptance criteria during discovery, requirement analysis, backlog refinement, and design review.

Who Is Responsible for UAT?

Knowing when UAT occurs leads to a second practical question: who owns it? The answer is not “QA alone.” QA can organise the activity, but only the appropriate business authority can decide whether the system is acceptable for use.

UAT succeeds when decision ownership and test support are separated clearly.

Internal QA teams or external software testing services can organise UAT, prepare scenarios, manage defects, and collect evidence. They should not replace the intended users’ judgement or make the business acceptance decision unless formally authorised to represent them.

A simple UAT responsibility matrix

R: Responsible · A: Accountable · C: Consulted · I: Informed

Adapt the matrix to the organisation. The important point is that accountability for approval must be explicit.

UAT Entry Criteria

Once ownership is clear, the team needs an agreed gate into UAT. Entry criteria protect business users from receiving an untestable build and keep the session focused on acceptance rather than basic troubleshooting.

Typical UAT entry criteria include:

• UAT scope and acceptance criteria are approved.
• Relevant system and integration testing is complete.
• The release candidate is deployed and versioned.
• No known defect blocks a critical UAT workflow.
• Known issues and workarounds are disclosed.
• The UAT environment is stable and sufficiently production-like.
• Required roles, accounts, permissions, and configurations exist.
• Representative test data is ready.
• Required integrations and notifications are available or appropriately simulated.
• UAT scenarios and instructions have been reviewed.
• Participants have access, time, and process context.
• Defect reporting, evidence capture, and support channels are ready.

A readiness check should confirm these conditions immediately before execution.

UAT Exit Criteria

Entry criteria answer “Are we ready to begin?” Exit criteria answer “Do we have enough evidence to decide?” They define when execution can stop without implying that every minor issue must disappear.

Typical UAT exit criteria include:

• Required business workflows have been executed.
• Every in-scope acceptance criterion has a result.
• Critical workflows pass.
• No open defect exceeds the agreed acceptance threshold.
• Fixed defects have been retested.
• Relevant regression checks have passed.
• Blocked tests have been resolved or assessed as explicit risk.
• Remaining issues have owners, workarounds, and agreed treatment.
• UAT evidence and summary reporting are complete.
• The authorised business owner records approval, conditional approval, or rejection.

Avoid an exit rule based only on a test pass percentage. One failed payment, migration, payroll, permission, or regulatory workflow may outweigh dozens of lower-risk passes.

How to Create a UAT Test Plan

Entry and exit rules form the boundaries, but they do not explain how the work will run. A UAT plan connects the business objective, participants, scenarios, environment, schedule, defect process, and final decision.

UAT plan template

1. Objective: The business decision UAT will support
2. Scope: Workflows, roles, features, regions, integrations, and data included
3. Out of scope: Explicit exclusions and their treatment
4. Acceptance basis: Requirements, user stories, process models, and criteria
5. Participants: Users, owners, support roles, and approval authority
6. Environment: Build, configuration, integrations, and production differences
7. Test data: Required records, accounts, ownership, and cleanup
8. Scenarios: Priorities, traceability, and expected outcomes
9. Schedule: Readiness, execution, defect fixes, retesting, and sign-off
10. Entry and exit criteria: Start and completion rules
11. Defect process: Categories, severity, owners, response times, and retest
12. Communication: Status cadence, support channel, and escalation
13. Evidence: What must be captured and retained
14. Sign-off: Possible outcomes, approver, and documentation

Keep the plan proportionate. A small SaaS feature may need a short page; a regulated migration or enterprise rollout may need detailed controls.

How to Perform UAT Step by Step

The plan establishes the operating rules. The following process turns it into an actual test cycle, beginning with the business outcome and ending with an authorised decision.

Step 1: Define the business objective

State what must be true for the release to be useful.

Weak objective: “Test the new order system.”

Better objective: “Confirm that sales and fulfilment users can create, approve, dispatch, and reconcile domestic orders using the agreed rules.”

Step 2: Select representative users

Choose users who:

• Understand the real workflow
• Represent relevant roles, locations, or customer groups
• Can distinguish a defect from a business preference
• Have time to prepare and test
• Are authorised to provide findings or acceptance input

Do not select only managers if frontline staff perform the workflow. Do not select only power users if the system targets occasional users.

Step 3: Review and refine acceptance criteria

Use concrete examples to identify:

• Business boundaries
• Role and permission differences
• Exception and approval paths
• Required reports and notifications
• Timing and cut-off rules
• Data retention and history
• Recovery after interruption or rejection

Resolve ambiguity before converting the criteria into scenarios.

Step 4: Map end-to-end business scenarios

Build scenarios around user goals, not pages.

Examples:

• Onboard a new employee and grant the correct access
• Create, approve, fulfil, and reconcile an order
• Submit an expense claim, return it for correction, and approve it
• Generate and validate a month-end report
• Amend a booking and process the correct refund

Prioritise scenarios according to frequency, business impact, compliance, revenue, data sensitivity, and change risk.

Step 5: Establish traceability

Map each scenario to its requirement or acceptance criterion.

Traceability reveals untested criteria and tests that lack a valid business basis.

Step 6: Prepare the UAT environment

The environment should reproduce the conditions that affect user acceptance:

• Correct release candidate
• Feature flags and business configuration
• User roles and permissions
• Representative database state
• Integrations, reports, emails, files, and scheduled jobs
• Supported browsers, devices, locales, and time zones
• Monitoring and evidence access

Document differences from production. A missing integration or simplified dataset may limit what the UAT result proves.

Step 7: Prepare realistic and safe test data

Provide:

• User accounts for every role
• Records in required lifecycle states
• Boundary and exception data
• Products, prices, limits, dates, and statuses
• Files and reports
• Unique identifiers for tracing results

Use synthetic or appropriately protected data. Define who owns setup, refresh, cleanup, and reset.

Step 8: Run a readiness or smoke test

Before the formal session, verify:

• Users can sign in.
• Core screens open.
• Test records exist.
• Integrations respond.
• Notifications or reports are available.
• Defects can be submitted.
• Support contacts are present.

This protects limited user time.

Step 9: Brief participants

Explain:

• UAT purpose and scope
• Scenarios and expected outcomes
• How to record actual results
• What evidence is required
• How to report blockers and feedback
• Which workarounds are known
• What participants should not change

Avoid leading users toward a pass. They should evaluate whether the process works as expected.

Step 10: Execute scenarios

For each scenario:

1. Confirm the user role and starting data.
2. Perform the business process.
3. Observe the outcome and important side effects.
4. Compare it with the acceptance criterion.
5. Record Pass, Fail, or Blocked.
6. Attach the required evidence.
7. Report any deviation.

Allow controlled exploratory time after scripted scenarios. Users often recognise workflow gaps only while working naturally.

Step 11: Triage findings

Not every UAT comment is a defect.

Agree on category, business impact, owner, release effect, and next action.

Step 12: Fix and retest

The appropriate user or authorised representative should retest material UAT failures after the fix. Also test affected neighbouring workflows where the change introduces regression risk.

Step 13: Prepare the UAT summary

Summarise:

• Build and scope tested
• Participants and dates
• Scenario and criterion coverage
• Pass, fail, and blocked results
• Critical findings and decisions
• Open defects and workarounds
• Environment limitations
• Residual business risks
• Recommendation

Step 14: Obtain sign-off

The business owner records one of three outcomes:

• Approved: The scope meets acceptance criteria and residual risk is accepted.
• Conditionally approved: Go-live is approved subject to documented conditions.
• Rejected: Blocking criteria remain unmet or risk is unacceptable.

Sign-off should identify the approver, build, scope, date, open issues, conditions, and evidence.

How to Write UAT Scenarios and Test Cases

The process above explains how UAT is managed. The individual scenarios determine whether it produces useful evidence. Good UAT cases describe recognisable work and allow users to judge the outcome without interpreting technical implementation details.

UAT scenario vs. UAT test case

A scenario describes a business goal:

A regional manager approves an expense claim within their authority.

A test case provides the conditions, data, actions, and expected outcome needed to validate it.

UAT test case template

Write in business language. Avoid database queries, API terminology, selectors, or technical setup unless the UAT participant genuinely needs them.

UAT Example: Expense Approval Workflow

The distinction becomes easier to see in a familiar workflow. The following example begins with business rules and turns them into concise scenarios for the relevant users.

Business rules

1. An employee can submit a complete expense claim.
2. A manager can approve claims up to ₹25,000.
3. Claims above ₹25,000 require a finance approver.
4. A returned claim can be edited and resubmitted.
5. An employee cannot approve their own claim.
6. Approval must appear in the audit history.

Example UAT cases

These scenarios test the workflow and authority rules from the users’ perspective. System testing should already have covered broader combinations, integrations, technical errors, and non-functional risks.

UAT Defect Severity and Release Decisions

Execution will usually produce a mixture of defects, usability concerns, missing requirements, and suggestions. Before deciding what blocks the release, the team must translate each finding into business impact.

Severity should reflect business impact.

Priority can differ from severity. A low-severity wording issue in a contractual disclosure may still require correction before release.

Useful UAT Metrics

After triage, stakeholders need a concise view of progress and risk. Metrics can help, provided they support judgement rather than replace it.

Metrics should support decisions, not create a false sense of precision.

Useful measures include:

• Percentage of in-scope criteria with a result
• Critical workflow pass status
• Passed, failed, blocked, and not-run scenarios
• Findings by business impact and category
• Retest completion
• Open conditions for approval
• Participant coverage by role or business area
• Time from finding to decision or fix

Avoid treating raw test-case count as quality. Ten well-designed scenarios may provide better acceptance evidence than one hundred click-by-click cases.

Manual and Automated UAT

Metrics explain what happened during a UAT cycle. Automation addresses a different question: which stable examples should be checked again in future releases? The answer is usually “some, but not all.”

UAT is commonly manual because it depends on user judgement. Some acceptance examples can be automated for regression.

Keep human-led:

• Workflow suitability
• Business judgement
• Usability and terminology
• New processes
• Unstructured user exploration
• Acceptance of workarounds and residual risk
• Formal business sign-off

Consider automating:

• Stable, repeatable acceptance examples
• Critical end-to-end regression journeys
• Data-driven business rules
• API-level acceptance outcomes
• High-frequency release checks

Automated tests can prove that a known example still passes. They cannot decide that intended users accept the system.

UAT Sign-Off Template

Whether the checks were manual or automated, UAT still ends with a human business decision. A concise sign-off record prevents “we thought it was approved” from becoming the release process.

Release/build:
UAT scope:
Execution dates:
Participants:

Acceptance criteria covered:
Passed:
Failed:
Blocked/not run:

Open defects and business impact:
Known workarounds:
Environment or evidence limitations:
Conditions and due dates:
Residual risks:

Decision: Approved / Conditionally approved / Rejected
Business owner:
Signature or recorded approval:
Date:

Store the sign-off with the test summary and evidence required by the organisation.

Common UAT Challenges and Solutions

Even a well-written plan can fail in practice if the wrong users, data, timing, or decision process are used. The following problems are common because they weaken the business evidence UAT is meant to provide.

1. Business users are involved too late

Result: Expectations surface after the product is built.
Improve it: Involve representatives during discovery, process mapping, refinement, and acceptance-criteria review.

2. UAT becomes another QA cycle

Result: Users report basic bugs instead of evaluating fitness for use.
Improve it: Enforce entry criteria and complete relevant system testing first.

3. The wrong users participate

Result: The workflow is approved by people who do not perform it.
Improve it: Include representative frontline, specialist, occasional, and approving roles as required.

4. Scenarios are too technical

Result: Users follow instructions without judging the business outcome.
Improve it: Write scenarios around goals and expected results in domain language.

5. Test data is unrealistic

Result: Important limits, roles, statuses, and exceptions remain untested.
Improve it: Design data with subject-matter experts and rehearse setup.

6. The environment differs from production

Result: UAT passes without proving real integration or configuration behaviour.
Improve it: Document every material difference and test unresolved risk elsewhere before approval.

7. Feedback is mixed with defects

Result: Triage becomes slow and scope expands informally.
Improve it: Separate defects, requirement gaps, environment issues, usability concerns, training needs, and enhancements.

8. There is no clear sign-off owner

Result: UAT continues indefinitely or approval is assumed.
Improve it: Name the accountable business owner in the UAT plan.

9. Open issues are accepted verbally

Result: Conditions and risk disappear after go-live.
Improve it: Record the issue, impact, owner, workaround, due date, and approval explicitly.

UAT Best Practices

Successful UAT is less about producing more test cases and more about creating trustworthy business evidence. Five practices matter most:

1. Start the conversation early. Involve representative users while workflows and acceptance criteria can still be clarified economically.
2. Protect the purpose of UAT. Use a stable, versioned build so participants validate fitness for use rather than repeat system testing.
3. Reproduce real work. Use representative roles, protected data, permissions, configurations, and complete processes.
4. Treat findings as decisions. Classify defects, requirement gaps, usability concerns, training needs, and enhancements before assigning release impact.
5. Close explicitly. Retest material fixes and tie approval, conditions, open risks, scope, and evidence to the exact release candidate.

When these practices are followed, UAT becomes a controlled decision process rather than a last-minute request for users to “take a look.”

Conclusion

User acceptance testing gives intended users and business owners structured evidence that software is suitable for real work.

A strong UAT process starts early with clear acceptance criteria, representative users, realistic scenarios, and explicit decision ownership. Formal execution begins only when the product and environment are ready. Findings are classified and retested, and the process ends with a documented acceptance decision.

UAT does not replace QA. It answers the final user-level question that technical testing cannot answer alone: is this system fit for the people and processes it was built to support?

Frequently Asked Questions

What is user acceptance testing?

User acceptance testing is performed by intended users or authorised business representatives to determine whether software supports real user needs and business processes well enough to be accepted for operational use.

Who should perform UAT?

Representative intended users and subject-matter experts should execute UAT, supported by a UAT lead, product or business analysts, QA, development, and operations. An authorised business owner makes the final decision.

When should UAT start?

Formal UAT should start after relevant system testing is complete, the release candidate is stable, critical blockers are resolved, and the environment, accounts, permissions, data, scenarios, participants, and support process are ready.

Is UAT the same as acceptance testing?

No. UAT is one form of acceptance testing focused on intended users. Operational, contractual, regulatory, alpha, and beta acceptance testing have different objectives, participants, evidence, and approval authorities.

What should a UAT test case contain?

A UAT test case should contain its business process, acceptance criterion, priority, user role, preconditions, representative data, essential actions, expected and actual outcomes, status, evidence, finding reference, tester, and execution date.

What happens after UAT is completed?

The team summarises coverage, results, unresolved findings, workarounds, conditions, and residual risks. The authorised business owner then approves, conditionally approves, or rejects the defined release and records the decision.

Can UAT be automated?

Stable acceptance examples can be automated as regression tests, but business judgement, workflow suitability, usability assessment, acceptance of residual risk, and formal sign-off remain human responsibilities.