User acceptance testing (UAT) is the final stage of testing, where real business users confirm that software does what they actually need before it goes live. Earlier testing asks "does it work?"; UAT asks "does it solve the problem we built it for?". It is the sign-off that a feature is ready for the people who will use it every day.
Definition: What Is UAT?#
User acceptance testing is acceptance testing performed by the intended users or business stakeholders, not the development team. Testers work through real-world tasks and scenarios to verify the software meets the agreed requirements and fits their workflow.
UAT is business-focused, not technical. The question is not whether the code is correct in isolation but whether the product is acceptable for release from the user's point of view.
Who Runs UAT and When#
UAT is run by the people the software is for: end users, clients, product owners, or business analysts who represent them. The development team supports the process but does not own the verdict.
It happens late in the cycle, after the engineering-led levels have passed:
- Unit and integration testing (developers)
- System testing (the whole product against requirements)
- User acceptance testing (business sign-off)
- Release
By the time UAT starts, the software should already be functionally stable. UAT is a confirmation step, not a place to find basic bugs.
UAT vs Beta Testing#
The two overlap and get conflated, but the intent differs:
| Aspect | UAT | Beta testing |
|---|---|---|
| Purpose | Formal sign-off against requirements | Broad real-world feedback |
| Testers | Specific business users or clients | A wide pool of external users |
| Setting | Structured scenarios | Natural, unguided usage |
| Outcome | Accept or reject for release | A backlog of feedback and issues |
UAT is the controlled, contractual check; beta is the wide, exploratory one.
Types of UAT#
- Business acceptance testing: Does it meet the business goals and process needs?
- Contract acceptance testing: Does it meet the criteria written into a contract?
- Regulatory acceptance testing: Does it comply with legal or industry rules?
- Operational acceptance testing: Are the supporting processes (backups, maintenance, support) ready for go-live?
How UAT Works#
A typical UAT cycle: define acceptance criteria from the requirements, build real-world test scenarios, give business users a near-production environment, let them work through the scenarios, log issues, and decide accept or reject. The deliverable is a decision, not just a bug list.
Limitations to Know#
- It runs late. Problems found in UAT are expensive, so UAT should confirm readiness, not catch defects earlier testing missed.
- User availability is a bottleneck. Business users have day jobs, so UAT can stall or get rushed.
- Feedback can be subjective. Without clear acceptance criteria, "I do not like it" is hard to action.
- Scope can drift. UAT sometimes surfaces new requirements rather than testing agreed ones.
Best Practices#
- Agree acceptance criteria before UAT starts. Decide what accept means up front, tied to requirements.
- Use real scenarios and real data. Test the workflows users actually do, not idealized happy paths.
- Recruit representative users. The people in UAT should reflect who will use the product day to day.
- Keep automated regression running underneath. UAT should validate fit, not re-find regressions a suite should have caught.
Conclusion#
UAT is the business world's final yes before release. It is run by users, measured against agreed criteria, and focused on whether the product solves the real problem, not whether the code compiles. It works best as a confirmation layer on top of strong earlier testing.
When UAT keeps tripping over regressions that should have been caught automatically, the cost is in maintaining that earlier layer. ObserveOne's Autopilot generates Playwright suites from a URL and heals them as the UI changes, so UAT stays focused on fit instead of old bugs.