UAT (User Acceptance Testing) is the final testing phase where real business users — not engineers — verify that software meets documented requirements and works in real-world scenarios before it goes live. It answers one question: is this the right product for the people who will use it? A formal sign-off ends UAT and authorises the release.
What is UAT in software development?
UAT, or User Acceptance Testing, is the final phase of the software development life cycle in which real business users test the software against agreed requirements before it is released to production. Unlike earlier testing phases that focus on technical correctness, UAT focuses on business correctness: does the software support the actual workflows of the people who will use it day to day?
When a custom software development team hands off a build, UAT is the final gate where the people who commissioned it confirm it does the job. The build may pass every unit test and integration test and still fail UAT if it solves the wrong problem, misses a critical workflow, or works in isolation but breaks when real users bring real data to it.
What does UAT stand for?
UAT stands for User Acceptance Testing. "User" refers to the business users or clients who commissioned the software, not internal testers. "Acceptance" refers to the formal sign-off that accepts the software as ready for production. "Testing" refers to the structured process of executing test cases against acceptance criteria. Together the acronym captures the essential idea: the people who need the software decide whether it is good enough to accept.
Why UAT is the last testing gate
UAT sits after unit testing, integration testing and system testing in the SDLC because it requires a stable, complete build and real-world business context that only end-users can supply. Earlier testing phases catch technical defects; UAT catches misalignment between what was built and what was actually needed. A defect found by QA during development costs a fraction of the same defect found in UAT — and a defect found in production after go-live can cost an order of magnitude more.
Why does UAT matter?
UAT matters because it is the only phase of testing that validates the business flow, not just the technical implementation. Engineering tests can confirm a login form works; UAT confirms the right users can access the right data through the right workflow in the context of their real job.
The cost-of-defect argument is central to UAT's value. Research consistently shows that defects caught in production cost 5–15× more to fix than defects caught in testing — and UAT is the last checkpoint before production. A missing field in a payment workflow, an export format that does not match the downstream tool, or a permission model that blocks the finance team from the reports they need: these are not bugs a unit test would catch, and each one can halt a launch or force an emergency release cycle (2026 analysis, Panaya / industry aggregates).
UAT also builds stakeholder confidence. When the business owner who requested the software runs the real scenarios and signs off, the release is no longer an act of technical faith — it is a confirmed business decision. That alignment is especially important for regulated industries, where UAT sign-off may be a compliance requirement in itself.
UAT vs QA testing: what is the difference?
The core difference: QA asks "did we build it right?" while UAT asks "did we build the right thing?" QA engineers run technical tests during development to catch defects in code, logic and integration. Business users run UAT after QA to confirm the software works for real people in real situations. Both are necessary; neither replaces the other.
| Dimension | QA Testing | UAT |
|---|---|---|
| Who runs it | QA engineers, testers | Business users, clients, product owners |
| When | During development (continuous) | After QA, before go-live |
| Focus | Technical correctness, code defects | Business requirements, real-world workflows |
| Test basis | Technical specifications, code | Business requirements, user stories, SRS |
| Goal | Bug-free build | Formal business sign-off for release |
| Environment | Dev / staging / test environment | UAT environment (production-like, clean data) |
In practice, QA and UAT work in sequence, not in competition. A build that has not passed QA should not reach UAT — you would be asking business users to hunt technical bugs that engineers should have caught. And a build that has passed QA but not UAT is not ready for release, no matter how clean the code. For the broader quality assurance process that UAT sits within, see our QA guide.
Who performs user acceptance testing?
UAT is performed by the people who will use or commission the software — not by the engineering or QA team that built it. The goal is an unbiased check from people whose real workflows the software must support. Common UAT participants include:
- End-users: the day-to-day operators of the system — clerks, analysts, agents, whichever role uses the software to do their job.
- Business analysts: who own the original requirements and can verify each acceptance criterion is met.
- Product owners: who represent the business and hold authority to sign off the release.
- Clients or commissioners: in outsourced development, the client organisation runs UAT to accept the deliverable.
- Subject-matter experts (SMEs): domain specialists (e.g. compliance officers, finance leads) who can validate that industry-specific rules are correctly implemented.
- Operational staff: IT administrators or support teams who will maintain the system after launch, especially for Operational Acceptance Testing (OAT).
What UAT participants should not be: the developers who wrote the code, the QA engineers who tested it, or anyone else who has been deeply involved in the build. Familiarity breeds assumption — insiders tend to test the happy path they know works, not the edge cases real users hit on day one.
Types of UAT
Not all UAT looks the same. The appropriate type depends on the product, the relationship between the team and the end-users, and any regulatory requirements that govern the release. The six main types:
- Alpha testing: internal UAT carried out by a limited group of users (usually within the organisation) in a controlled lab or staging environment. Typical for packaged software before beta release.
- Beta testing: external UAT carried out by a representative sample of real end-users in a production-like environment. Feedback gathered before the full public release.
- Contract Acceptance Testing (CAT): verifies that the software meets the specific requirements outlined in a development contract — common in outsourced builds where acceptance equals payment.
- Regulation / Compliance Acceptance Testing: confirms the software satisfies legal or industry standards (HIPAA, GDPR, PCI-DSS, financial reporting rules). Sign-off here may itself be a compliance artefact.
- Operational Acceptance Testing (OAT): tests operational readiness — backup and recovery, disaster recovery, maintenance windows, performance under real load, and system administration tasks. Ensures the software can be run and supported in production.
- Black-box testing: end-to-end UAT where testers validate business outcomes without knowledge of the internal code or architecture — the closest simulation of real user experience.
The UAT process, step by step
UAT follows a defined sequence because each step depends on the one before it. Skipping the planning phase or jumping straight to execution without prepared test cases is the single most reliable way to produce inconclusive results — and a sign-off that does not actually mean anything. The canonical process in 2026:
- Plan and analyse requirements. Define the UAT scope, identify the business use cases and user stories to be tested, confirm entry criteria, assign roles and set the timeline. Document this in a UAT test plan.
- Design UAT test cases. Write test cases based on business requirements, user stories and the System Requirements Specification (SRS). Each test case maps to one or more acceptance criteria and includes the test data needed to run it.
- Set up the UAT environment and test data. Provision a clean, stable environment that mirrors production. Prepare representative test data — not production data, but realistic enough to surface real workflow issues.
- Execute test cases and log defects. Business users run the test cases, following the scripts. Any deviation from expected results is logged as a defect in a tracking tool (Jira, TestRail, Azure DevOps), with steps to reproduce and severity.
- Developers fix defects and retest. The development team fixes the logged defects and the UAT team retests the affected flows. Critical defects must be resolved before sign-off; minor defects may be deferred to a post-release backlog by stakeholder agreement.
- Formal sign-off and go-live authorisation. Once all exit criteria are met — test cases executed, critical defects resolved, UAT summary report filed — the business owner or product owner signs the acceptance document. This is the formal authorisation to release.
This process sits in the software development life cycle between system testing and release. How it is scheduled differs between Agile and Waterfall — see the section below.
How to write UAT test cases and acceptance criteria
A UAT test case is only as useful as its acceptance criteria — without them, "pass" or "fail" is a matter of opinion, not evidence. Acceptance criteria describe the exact conditions a feature must meet for the business to accept it. They are typically written as: "Given [context], when [action], then [expected outcome]."
Good acceptance criteria come from business requirements and user stories, not from the implementation. If a user story says "As a finance manager, I need to export invoice data as CSV," the acceptance criteria specify the exact columns, date format, character encoding and file-size limit — so there is no ambiguity about what "works" means on UAT day.
Entry and exit criteria
Entry criteria define what must be true before UAT begins:
- QA has signed off on all test phases (unit, integration, system)
- A stable build is deployed to a dedicated, clean UAT environment
- Representative test data is prepared and loaded
- UAT test cases are reviewed and approved by the business
- UAT participants are available, briefed and scheduled
Exit criteria define what must be true before UAT ends with a sign-off:
- All planned test cases have been executed
- All critical and high-severity defects are fixed and retested
- The business stakeholder or product owner has signed the acceptance document
- A UAT summary report is filed (test cases run, pass rate, open defects and disposition)
Entry and exit criteria convert UAT from a subjective "feels right" exercise into a verifiable gate. For the wider delivery context, see our software development methodologies guide and our software development best practices guide.
UAT in Agile vs Waterfall
The fundamental difference: in Waterfall, UAT is a single end-phase gate; in Agile, acceptance testing runs continuously, sprint by sprint.
In a Waterfall project, UAT comes at the end of the development lifecycle, after the entire system is built and QA-tested. Business stakeholders see the software for the first time in UAT. This concentrates risk — if the build diverges from requirements, all the misalignment surfaces at once. Waterfall UAT plans are detailed and formal because there is only one chance to run them before the release decision.
In an Agile project, acceptance testing is embedded in each sprint. At the end of a sprint, the product owner reviews the completed stories and accepts or rejects them against the sprint goal and acceptance criteria. The formal end-of-project UAT still exists — but it is a shorter confirmation, not a discovery exercise, because the business has been validating incrementally throughout. This is why most Agile teams describe "done" as including acceptance by the product owner, not just passing technical tests. For UAT's place in the full SDLC, see our software development life cycle guide.
UAT checklist and best practices for 2026
A 2026 UAT runs against tighter timelines, distributed teams and higher compliance-evidence demands than UAT of five years ago. These best practices account for the current context:
- Agree business objectives before writing a single test case. Every test case should trace to a business objective, not just a feature. If you cannot state why a test case matters to the business, it probably does not belong in UAT.
- Use a clean, dedicated UAT environment. Do not run UAT in a dev or staging environment that developers are still pushing to. Test environment instability is the fastest way to invalidate results and destroy tester confidence.
- Prepare representative test data — not production data. Real data often contains personal information that creates GDPR / CCPA exposure in a test environment. Anonymised but realistic data sets surface the same workflow problems without the compliance risk.
- Use a test-management tool to log and sign off results. Spreadsheets lose traceability. Tools like TestRail, Xray or Azure Test Plans create an auditable record of what was tested, by whom, and what was found — essential for regulated industries and client-facing UAT.
- Plan for distributed UAT users. In 2026, UAT participants are frequently spread across time zones. Async test execution with clear video-recorded evidence and asynchronous defect comments prevents the bottleneck of live, synchronous sessions.
- Capture compliance evidence during execution. For regulated systems (healthcare, fintech, government), UAT must produce not just a sign-off but a trace: screen recordings, log exports, tester attestations. Build this into the UAT plan, not as an afterthought.
- Set a clear defect disposition policy before UAT starts. Define which defect severities block release and which can be deferred. Without this, every minor bug becomes a negotiation on release day.
Common UAT mistakes to avoid
Most UAT failures trace back to one of five predictable mistakes. Avoiding them costs almost nothing; recovering from them costs a delayed release or a production incident.
- Starting UAT without acceptance criteria. If there is no documented definition of "done" for each feature, UAT produces opinions, not evidence. Write acceptance criteria before development begins, not after.
- Using QA engineers or developers as UAT testers. Engineers know where the bodies are buried and test around them. Real users find the problems that matter to real workflows. UAT must involve people who are genuinely new to the system.
- Using stale or production data. Dirty test data — a mix of old records, edge-case values, or production PII — hides real bugs under data noise and creates compliance exposure. Prepared, representative data is non-negotiable.
- No formal sign-off gate. "Everyone felt good about it" is not a sign-off. A formal sign-off document, signed by the named business owner, is both an audit artefact and a clear moment of business decision. Without it, the release is always ambiguous.
- Squeezing the UAT timeline. UAT is the last thing before production and therefore the first thing to get compressed when a project runs late. A rushed UAT that misses critical scenarios is worse than a short delay — it trades a known cost (delay) for an unknown one (production defects).
FAQ
What is UAT in software development?
UAT (User Acceptance Testing) is the final phase of the software development life cycle in which real business users — not engineers or QA staff — test the software against documented requirements in real-world scenarios before it goes live. UAT answers one question: is this the right product for the people who will use it? A successful UAT ends with a formal sign-off that authorises the go-live.
What does UAT mean in software development?
UAT stands for User Acceptance Testing. In software development, it means testing carried out by the actual end-users, business stakeholders or clients who commissioned the software. Its purpose is to validate that the system meets the agreed business requirements and acceptance criteria — distinct from QA testing, which is performed by engineers during development to catch technical defects.
What is the difference between UAT and QA?
QA (Quality Assurance) is run by QA engineers during development to verify the software is built correctly — covering unit, integration and system testing. UAT is run by business users after QA to confirm the software is the right product for real users. QA asks "did we build it right?"; UAT asks "did we build the right thing?". QA catches technical defects; UAT validates business workflow and end-to-end real-world scenarios.
Who performs user acceptance testing?
UAT is performed by the people who will actually use or commission the software: end-users, business analysts, product owners, clients or other business stakeholders. It is explicitly not performed by the development or QA team who built the system, because the goal is an unbiased check from the people whose real-world workflows the software must support.
What are the main types of UAT?
The main types of UAT are: Alpha testing (controlled environment, internal users), Beta testing (real users in production-like conditions), Contract Acceptance Testing (CAT — verifies contractual requirements), Regulation/Compliance Acceptance Testing (validates legal or industry standards), Operational Acceptance Testing (OAT — checks operational readiness: backup, recovery, maintenance), and Black-box testing (end-to-end validation without knowledge of internal code).
What are the entry and exit criteria for UAT?
Entry criteria for UAT typically include: QA sign-off complete, a stable build deployed to a clean UAT environment, representative test data prepared, UAT test cases reviewed and approved, and business users available and briefed. Exit criteria typically include: all planned test cases executed, all critical and high-severity defects fixed and retested, a formal sign-off document signed by the business stakeholder or product owner, and a UAT summary report filed.
Last updated 25 August 2026. UAT timelines, defect-cost ratios and best practices reflect 2026 industry sources including Panaya, AltexSoft, Splunk and Abstracta. Specific durations and costs depend on project scope, team size and regulatory requirements.
