User acceptance testing (UAT) is the final testing phase before a release, where the people who will actually use the software check that it does the job they need, in conditions close to real use. It answers one question: can we accept this release? Earlier testing asks whether the software works as built. UAT asks whether it works for the business.
This guide covers what UAT is, how it differs from other testing, a step-by-step process, how to write UAT test cases, a copyable template, and how to collect feedback testers can actually act on.
What does UAT stand for?
UAT stands for user acceptance testing. You’ll also see it called acceptance testing, end-user testing, beta testing (when the users are customers) or business acceptance testing. In agile teams, acceptance tests are often written per user story, as the conditions that story must meet to count as done.
UAT vs other types of testing
| Type | Question it answers | Who usually tests |
|---|---|---|
| Unit and integration tests | Does each piece of code work, and do the pieces work together? | Developers, automated |
| System integration testing (SIT) | Does the whole system work with its connected systems and data? | QA team |
| QA / functional testing | Does the software match the specification? | QA team |
| User acceptance testing (UAT) | Does it let real users do their work, so we can accept it? | Business users, customers, product owners |
| Bug bash | What breaks when many people use it at once? | Staff from across the company |
The key difference: QA tests against the specification, while UAT tests against the real need. A feature can pass QA and still fail UAT, because the spec missed how people actually work. For a group defect hunt before UAT, see how to run a bug bash.
Types of UAT
- Alpha testing: internal users test in a controlled environment before anyone outside sees the release.
- Beta testing: a group of real customers uses the release in their own environment and reports issues.
- Business or operational acceptance testing: business owners check workflows, and operations teams check backups, monitoring and support readiness.
- Contract and regulatory acceptance testing: the release is checked against contractual terms or legal requirements.
The UAT process in 7 steps
- Define acceptance criteria. For each requirement or user story, write what “done” looks like from the user’s point of view, before testing starts. Vague criteria lead to arguments at sign-off.
- Plan the test. Scope, dates, testers, environment, entry criteria (for example: QA finished, no open blockers) and exit criteria (for example: all critical test cases pass, no open high-severity defects).
- Choose the testers. Pick people who do the work every day: the finance clerk for an invoicing change, not the finance director. Brief them on scope and how to report.
- Prepare the environment and data. A UAT environment that mirrors production: realistic data (anonymized), the right roles and permissions, and connected systems.
- Write the test cases. Business scenarios, not button clicks. See the next section.
- Run the tests and log defects. Testers record pass or fail for each case and report anything that fails, with evidence.
- Fix, retest and sign off. The team fixes defects, testers confirm the fixes, and the business owner formally accepts (or rejects) the release against the exit criteria.
How to write UAT test cases
A UAT test case describes a real task a user needs to complete, with enough detail that any tester can run it and agree on the result. Good UAT test cases:
- start from a business scenario (“Approve a supplier invoice over $10,000”), not a technical function;
- name the user role and starting data;
- list steps a non-technical tester can follow;
- state an expected result that is observable and unambiguous;
- link to the requirement or user story they verify.
UAT test case examples
These examples are fictional, for a billing feature:
| ID | Scenario | Role | Expected result |
|---|---|---|---|
| UAT-01 | Upgrade from the Starter to the Growth plan mid-month | Account owner | Prorated charge shown before confirming; invoice matches |
| UAT-02 | Replace an expired card | Billing admin | New card saved; failed invoice retried automatically |
| UAT-03 | Try to change the plan without billing rights | Member | Plan settings visible but read-only, with a clear message |
| UAT-04 | Download last year’s invoices | Finance user | All 12 invoices download as PDF with correct tax IDs |
UAT template
Use one row per test case. A spreadsheet or your test management tool works:
Test case ID: Requirement / user story: Scenario: Tester and role: Preconditions (account, data, environment): Steps: 1. 2. 3. Expected result: Actual result: Status: Pass / Fail / Blocked Defect link (if failed): Evidence (screenshot or recording): Tested on (date, browser, device): Notes:
Reporting UAT defects so they get fixed
UAT testers are usually business users, not testers by trade, and that’s where UAT stalls: a “fail” with the note “doesn’t work” sends the developer back to the tester with questions, and the retest window closes. Make it easy to give evidence:
- Ask for a recording, not a paragraph. A short screen recording shows the exact steps, data and error. With a browser extension like Screendesk, the recording also carries console logs, network requests and browser details, so developers can reproduce the issue without a follow-up call.
- Mark up screenshots. For layout and copy issues, a screenshot with the problem circled and a one-line note is enough. Blur real customer data if UAT runs on a copy of production.
- Use one defect format. Title, steps, expected vs actual, severity, environment and evidence. Our bug report templates and Jira bug report guide have fields you can reuse.
- Separate defects from change requests. “The total is wrong” is a defect. “I’d like the total in bold” is a change request. Log them differently, or sign-off gets blocked by wishes.
UAT sign-off
Sign-off is the business owner’s formal decision to accept the release. A sign-off document typically records the scope tested, the test cases passed, failed and blocked, open defects with their severity and agreed workaround or fix date, the decision (accepted, accepted with conditions, or rejected), and the name, role and date of the person signing. Keep it short and factual: it’s the record you’ll return to if a problem appears after launch.
UAT checklist
- Acceptance criteria written for every requirement in scope
- Entry and exit criteria agreed with the business owner
- UAT environment mirrors production; test data anonymized
- Testers chosen, briefed and given accounts for each role
- Test cases written as business scenarios and linked to requirements
- One defect format and one place to log defects
- Retest time planned after the fix window
- Sign-off owner named
Frequently asked questions
What is UAT in software testing?
UAT is the last testing phase, where intended users confirm the software supports their real tasks before it’s released. It follows unit, integration, system and QA testing.
Who performs UAT?
End users or their representatives: business users, customers in a beta, product owners or subject-matter experts. The QA team often organizes UAT but shouldn’t be the only testers.
What’s the difference between SIT and UAT?
System integration testing checks that the system works technically with its connected systems and data. UAT checks that users can do their work with it. SIT usually comes first.
What is a UAT environment?
A separate environment set up to mirror production as closely as possible, with realistic (anonymized) data, so test results predict how the release will behave after launch.
How long does UAT take?
It depends on scope. One to two weeks is common for a significant release, including time to fix defects and retest. Plan the retest time explicitly. It’s the part most often squeezed.
