User Acceptance Testing (UAT): Definition, Process, and Best Practices

User acceptance testing (UAT) is acceptance testing carried out by intended users or their representatives in a simulated operational environment. It checks whether the product supports agreed user needs, business processes, and acceptance criteria well enough for an authorized person to accept the release. The ISTQB glossary defines UAT as acceptance testing by future users in a simulated operational environment focused on user requirements and needs.

UAT is evidence for an acceptance decision. It does not prove that no defects remain, and it does not replace developer checks, system testing, security testing, or performance testing.

What is UAT testing?

UAT answers a business question: Can the intended users complete the agreed tasks and achieve the required outcomes in the intended context?

A useful UAT result connects four things:

User: the representative person or role performing the work.
Context: the environment, permissions, data, integrations, and business conditions.
Action: the meaningful workflow the user must perform.
Outcome: the observable result that determines pass, fail, or blocked.

Acceptance testing is broader than UAT. Depending on the project, acceptance may also be contractual, regulatory, operational, alpha, or beta testing. Name the acceptance basis and decision-maker for your project instead of treating these labels as interchangeable.

UAT vs. QA, system testing, and operational acceptance

Activity	Primary owner	Question answered	Typical evidence
UAT	Intended users or authorized business representatives	Does the product support real user needs and business outcomes?	Scenario results, business data, user feedback, acceptance decision
System testing	Testers and engineers	Does the integrated system conform to technical and functional requirements?	Automated and manual test results, defect reports
QA verification	QA and delivery teams	Does the implementation meet defined quality conditions?	Test reports, traceability, regression results
Operational acceptance	Operations or service owners	Can the service be run, supported, monitored, backed up, and recovered?	Runbooks, monitoring checks, recovery evidence

UAT should not be described as simply “the final QA test.” The owner of the acceptance decision, the criteria being judged, and the evidence required are different.

Who performs UAT?

UAT is collaborative, but intended users or their authorized representatives must provide the user perspective. The ISTQB acceptance-testing materials identify product owners, business analysts, testers, test analysts and engineers, consultants, test managers, UAT testers, and developers as participants in software acceptance work.

Role	Responsibilities
Representative users or customer representatives	Describe real workflows, terminology, priorities, acceptable outcomes, and usability concerns; execute scenarios and provide evidence.
Product owner or business sponsor	Set business priorities, resolve scope questions, and identify the accepting authority.
Business analyst	Turn needs and business rules into observable acceptance criteria and scenarios.
Tester or test analyst	Improve coverage, make cases repeatable, support execution, record evidence, and help triage issues.
Developer or delivery team	Explain intended behavior, investigate failures, fix defects, and support retesting without substituting for user judgment.
Test or delivery lead	Coordinate scope, environment readiness, defect handling, reporting, and sign-off preparation.
Accepting authority	Reviews results, unresolved risks, and criteria, then records accept, reject, or conditional acceptance.

UAT process: a practical step-by-step method

1. Agree scope and decision rules

Before execution, document the release or change, user groups, business processes, exclusions, participants, decision authority, and applicable contract or regulation. Agree:

Entry conditions: which build, environment, integrations, accounts, data, and documentation must be ready.
Exit criteria: which critical scenarios must pass, how blocked cases are handled, and what evidence is required.
Severity rules: which unresolved issues block acceptance and who can accept residual risk.
Decision options: accepted, rejected, or accepted with explicitly recorded conditions.

There is no universal pass percentage or defect threshold. Set the rule with the people who own the business decision.

2. Turn needs into testable acceptance criteria

Decompose each important requirement into a condition that can be observed. Include business rules, permissions, calculations, integrations, notifications, reporting, and relevant failure paths. Avoid criteria such as “the workflow is easy” unless you define the user outcome and evidence that make “easy” observable.

Prioritize high-impact processes and rules. UAT does not need to duplicate every unit, integration, or edge-case test.

3. Write user-centered scenarios

A scenario should state a user goal and expected result in business language. Given/When/Then is useful:

Given an approved customer account with an unpaid invoice
And the user has billing-admin permission
When the user records a payment for the full amount
Then the invoice status becomes Paid
And a receipt is available in the account history

Describe semantic actions rather than brittle interface clicks unless the interaction itself is under test. Keep cases atomic and independent where possible so they can run in different orders.

4. Prepare users, data, and environment

Recruit users who represent the roles, experience levels, regions, and constraints of the intended audience.
Provide an environment close enough to operational use for the results to be meaningful.
Create controlled, realistic data and protect personal or confidential information.
Verify accounts, roles, feature flags, integrations, email delivery, payment sandboxes, and external dependencies.
Explain scope, scenario instructions, result labels, evidence requirements, and how to report issues.

These preparations are practical implications of collaborative acceptance testing; the exact checklist depends on risk and context.

5. Execute and record evidence

For every case, record the criterion or scenario, starting conditions, actual result, status, timestamp, user or role, environment/build, and supporting evidence. Use these statuses consistently:

Status	Meaning
Passed	The observed result meets the agreed criterion.
Failed	The observed result does not meet the criterion and is reproducible or sufficiently evidenced.
Blocked	The case could not be evaluated because a dependency, access problem, environment issue, or defect prevented execution.
Not run	The case has not yet been attempted.
Out of scope	The case is excluded by the agreed scope; record who approved the exclusion.

Keep exploratory observations and newly requested behavior separate from failures against pre-agreed criteria. A user may discover a valuable requirement during UAT without that discovery automatically making the current release unacceptable.

6. Triage, fix, and retest

Each issue should include a concise title, user role, preconditions, reproduction steps, expected result, actual result, impact, environment/build, and evidence. Assign an owner and decide whether it blocks acceptance under the rules agreed in step 1.

After a fix, retest the failed path and run relevant regression scenarios. Do not mark a case passed merely because a developer says it is fixed.

7. Review results and record the decision

Prepare a decision record showing scope, participants, executed and blocked cases, failures, fixes, unresolved issues, accepted risks, and the accepting authority. The decision should explicitly state whether the release is accepted, rejected, or conditionally accepted, with conditions and owners if applicable.

What should a UAT test case include?

A practical test-case template contains:

ID and title: a stable identifier and business-readable name.
Business objective: why the scenario matters.
Persona and permissions: the user role and required access.
Preconditions: account state, data, integrations, and configuration.
Steps or Given/When/Then: actions stated at the right level of detail.
Expected result: observable business outcomes, including generated records or messages.
Priority and risk: impact if the workflow fails.
Evidence fields: result, timestamp, environment, build, notes, and attachments.
Defect link: reference to any issue and retest result.

Best practices for reliable UAT

Involve representative users while criteria and scenarios are still being shaped.
Prioritize critical business processes, high-impact rules, and realistic alternate paths.
Use realistic but controlled data with appropriate privacy and access safeguards.
Agree the handling of defects, questions, blocked tests, and out-of-scope observations before sessions begin.
Keep an auditable result trail and retest affected cases after fixes.
Include non-functional acceptance concerns when they affect the decision. ISTQB acceptance-testing material includes usability and user experience, performance efficiency, and security; a short UAT session does not replace specialist performance or security testing.
Define entry and exit conditions and the accepting authority before execution.
Report evidence by user workflow and business outcome, not only by technical component.

Capturing screenshots as UAT evidence

Visual evidence helps reviewers verify what the user actually saw, especially for invoices, dashboards, permissions, responsive layouts, and error states. Capture the relevant state after the meaningful action, include enough context to identify the scenario, and avoid exposing personal or secret data.

For a self-managed browser capture, Playwright can open the UAT environment, authenticate with a test account, perform a workflow, and save a screenshot:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage({
  viewport: { width: 1440, height: 900 },
});

await page.goto('https://uat.example.com/invoices/123', {
  waitUntil: 'networkidle',
});
await page.getByRole('button', { name: 'Record payment' }).click();
await page.getByLabel('Amount').fill('125.00');
await page.getByRole('button', { name: 'Save payment' }).click();
await page.getByText('Payment recorded').waitFor();
await page.screenshot({ path: 'evidence-invoice-paid.png', fullPage: true });

await browser.close();

Store the build number, scenario ID, timestamp, viewport, and test-account identifier beside the file. Use disposable accounts and redact sensitive values before sharing evidence.

Performance, reliability, and cost considerations

UAT execution

Run high-risk scenarios first when the session window is short.
Separate environment failures from product failures so blocked cases do not look like user rejections.
Keep scenarios independent and data resettable to reduce reruns.
Schedule retest capacity; fixes discovered late in UAT still require regression checks.
For performance-sensitive acceptance criteria, define workload, response-time measure, and measurement environment separately from ordinary user walkthroughs.

Evidence capture

Full-page images can be large; capture a specific element when the decision concerns one component.
Use a consistent viewport and device scale for comparable evidence.
Wait for the business state, not merely a fixed delay, before capturing.
Cache immutable pages when appropriate, but disable caching for workflows whose state must be freshly verified.
Estimate storage and review time from the number of scenarios, retries, and evidence files.

Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. One request returns a PNG, JPEG, WebP, or PDF. Cookie and consent banners, newsletter popups, and chat widgets are removed before capture; bot checks, blank pages, timeouts, failed loads, and cache hits are not billed. Responses identify the result with X-Page-Verdict and X-Billed headers. Its MCP server lets Claude, Cursor, and other MCP clients use take_screenshot, get_page_info, and capture_pdf.

See the ScreenshotNeo API documentation for all options. This cURL request captures a UAT page:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://uat.example.com/invoices/123 -o uat-evidence.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://uat.example.com/invoices/123"},
    timeout=90,
)
r.raise_for_status()
open("uat-evidence.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://uat.example.com/invoices/123'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('uat-evidence.webp', Buffer.from(await res.arrayBuffer()));

Use custom headers, cookies, authorization, a wait-for selector, custom JavaScript, hidden selectors, a chosen viewport, full-page mode, element capture, PDF settings, caching TTL, async jobs, signed webhooks, or bulk capture when your UAT evidence process needs them. Plans include every feature: 1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account and capture up to 1,000 screenshots a month without a card.

Common UAT problems and fixes

Problem	Likely cause	Fix
Users disagree about what “pass” means	Criteria or decision rules were not agreed early.	Rewrite the criterion as an observable outcome and have the accepting authority approve it.
Most cases are blocked	Environment, accounts, data, or integrations were not prepared.	Track readiness separately, assign owners, and restart blocked cases after dependencies are fixed.
Users report requests as defects	New requirements are mixed with failures against the current scope.	Classify each item as defect, clarification, enhancement, or out of scope.
Results cannot be reproduced	Missing build, role, data, steps, or evidence.	Record preconditions, exact actions, environment, timestamp, and screenshots or recordings.
A fix passes but breaks another workflow	Only the original case was retested.	Run targeted regression scenarios around the changed rule or integration.
Screenshot shows a cookie banner or popup	The capture happened before the page was prepared for evidence.	Dismiss or remove overlays before capture, or use ScreenshotNeo’s consent and popup removal.
Screenshot is blank or times out	The page failed to load, required authentication, or was blocked.	Verify access and readiness; with ScreenshotNeo, inspect `X-Page-Verdict` and `X-Billed` to distinguish failures from billable clean shots.
Evidence leaks sensitive data	Production-like data was copied without controls.	Use masked or synthetic data, least-privilege accounts, and a redaction review before sharing.

When is UAT complete?

UAT is complete when the agreed scope has been exercised sufficiently, results and evidence are recorded, blocking issues are resolved or explicitly accepted, affected cases are retested, and the authorized stakeholder records the decision. “All tests passed” is not a universal requirement: the decision depends on the criteria, risk tolerance, and authority agreed before execution.

UAT checklist

Scope, user groups, exclusions, and acceptance authority are named.
Entry conditions and exit criteria are written and approved.
Critical workflows and business rules have observable scenarios.
Representative users, accounts, data, and integrations are ready.
Every result has a status, environment, build, timestamp, and evidence where needed.
Defects, blocked cases, questions, and enhancements are classified separately.
Fixes have been retested with relevant regression coverage.
Unresolved risks have an owner and explicit acceptance decision.
The final decision and supporting record are stored where stakeholders can review them.

FAQ

Is UAT performed only at the end of a project?

No. Scenarios and criteria can be prepared as requirements evolve, and execution can occur around a release or in increments that suit the delivery lifecycle.

Can developers perform UAT?

Developers can support UAT and may represent users when formally authorized, but UAT loses its purpose when the delivery team substitutes its own judgment for that of intended users or the accepting authority.

Does UAT include security and performance testing?

Security, usability, and performance efficiency can be acceptance concerns when they affect users and the decision. Specialist testing is still needed for deep security or performance assurance.

How many UAT test cases are enough?

Enough to provide credible evidence for the agreed decision, with priority given to critical workflows, high-impact rules, and realistic alternate paths. No universal count applies.

What is conditional acceptance?

It is an explicit decision to accept while recording specific unresolved issues, risks, owners, and deadlines. Use it only when the accepting authority agrees to the conditions.