User acceptance testing (UAT) is the final validation phase where real users or business stakeholders verify that a product or feature meets its acceptance criteria before release to production.
UAT is the last line of defense before a feature reaches your customers. Done well, it catches integration failures, edge cases, and usability issues that unit and integration tests miss. Done poorly, it creates false confidence — a rubber-stamp approval that lets critical bugs through.
This guide shows product managers how to own UAT from test planning through go/no-go decision.
What UAT Tests That Other Tests Don't
| Test Type | What It Catches | What It Misses | |-----------|----------------|----------------| | Unit tests | Individual function correctness | Integration issues, user context | | Integration tests | API contracts, service wiring | Real user flows, business logic edge cases | | QA regression | Known bug regressions | New user scenarios, business acceptance criteria | | UAT | Business requirement fulfillment | Technical implementation details |
UAT answers the question: does this feature actually do what the business needed it to do in the way real users will use it?
H3: Who Should Conduct UAT?
Ideal UAT participants:
- Power users who use the feature daily and know edge cases
- Business stakeholders who defined the acceptance criteria
- Customer success representatives who know the most common support issues
- Product manager as observer and defect triage owner
Never use developers to conduct UAT for code they wrote. Confirmation bias produces rubber-stamp results.
Planning the UAT Cycle
H3: Step 1 — Define Acceptance Criteria Before Development Starts
Acceptance criteria are the contract between product and engineering. They must be:
- Specific: "Users can export up to 10,000 rows to CSV in under 5 seconds"
- Testable: Each criterion has a pass/fail outcome
- Business-oriented: Describes what the user can do, not how the system works
- Complete: Covers happy path, error states, and edge cases
According to Lenny Rachitsky writing on product execution, the most common cause of failed UAT is acceptance criteria written after development — when they become a description of what was built rather than a standard for what should have been built.
H3: Step 2 — Build the UAT Test Plan
A UAT test plan includes:
- Scope: Which features and user flows are in scope for this cycle
- Test environment: Staging or production-like environment with realistic data
- Participants: Named testers with their roles
- Timeline: Start date, end date, defect fix window, sign-off deadline
- Entry criteria: What must be true before UAT begins (QA complete, no P0 bugs)
- Exit criteria: What must be true to achieve sign-off (all P1 and P2 defects resolved)
H3: Step 3 — Write UAT Test Cases
Each test case contains:
- Test case ID (for defect tracking)
- User role (who is performing the action)
- Preconditions (what state the system must be in)
- Steps (numbered, specific actions)
- Expected result (what should happen)
- Actual result (what did happen during testing)
- Pass/Fail
Running the UAT Cycle
H3: Defect Severity Classification
| Severity | Definition | UAT Impact | |----------|-----------|------------| | P0 — Blocker | System unusable, data loss, security breach | Stop UAT immediately | | P1 — Critical | Core user flow broken with no workaround | Must fix before sign-off | | P2 — Major | Important flow broken with workaround available | Must fix before sign-off | | P3 — Minor | Edge case, cosmetic, or UX issue | Fix in next sprint, sign-off possible | | P4 — Enhancement | Not a defect, new request | Log in backlog, not in UAT |
According to Shreyas Doshi on Lenny's Podcast, the biggest UAT anti-pattern is treating every bug as equal — it paralyzes launches because P4 enhancements block release as much as P0 blockers. Severity classification is non-negotiable.
H3: The Go/No-Go Decision
Go criteria:
- All P0 and P1 defects resolved and re-tested
- All P2 defects resolved or accepted with documented mitigation
- Sign-off from all required business stakeholders
- Rollback plan documented and tested
No-Go criteria:
- Any open P0 or P1 defect
- Business stakeholder sign-off not received
- Test environment significantly different from production
UAT Anti-Patterns to Avoid
H3: The Rubber Stamp
Stakeholders approve without actually testing. This happens when UAT is scheduled too late (no time to find defects), test cases are too vague, or stakeholders don't have access to a production-like environment.
Fix: Schedule UAT with enough buffer before launch for a defect fix window. Block calendar time for stakeholders. Provide them with a pre-populated test environment.
H3: Scope Creep During UAT
New requirements emerge during UAT. Testers request features that weren't in the acceptance criteria. UAT turns into a second product discovery session.
Fix: When a tester raises something that wasn't in the acceptance criteria, log it as a new request in the backlog. It's not a defect — it's new scope.
According to Gibson Biddle on Lenny's Podcast discussing execution discipline, the most disciplined product teams treat UAT as a validation exercise, not a discovery exercise. UAT tests what was agreed; it is not a forum for expanding scope.
FAQ
Q: What is user acceptance testing? A: UAT is the final validation phase where real users or business stakeholders verify that a product or feature meets its acceptance criteria before release to production.
Q: Who should conduct UAT? A: Power users who use the feature daily, business stakeholders who defined the acceptance criteria, and customer success representatives who know common edge cases. Developers should not conduct UAT for code they wrote.
Q: What is the difference between UAT and QA testing? A: QA tests technical correctness — are there bugs? UAT tests business requirement fulfillment — does this feature do what the business needed in the way real users will use it?
Q: What defect severity levels should UAT use? A: P0 blockers stop UAT immediately. P1 critical and P2 major defects must be resolved before sign-off. P3 minor issues can be accepted for post-launch fixing. P4 enhancements are new requests, not defects.
Q: What are the go/no-go criteria for UAT sign-off? A: All P0 and P1 defects resolved and re-tested, all P2 defects resolved or mitigated, business stakeholder sign-off received, and rollback plan documented and tested.
HowTo: Run User Acceptance Testing
- Define specific, testable acceptance criteria before development starts — each criterion must have a clear pass or fail outcome
- Build a UAT test plan with scope, test environment, named participants, timeline, and entry and exit criteria
- Write test cases with user role, preconditions, numbered steps, and expected versus actual results for each flow
- Classify all defects by severity P0 through P4 and enforce that only P0 and P1 block launch
- Conduct a go/no-go meeting with all P0 and P1 defects resolved and written sign-off from business stakeholders
- Log any new requirements raised during UAT as backlog items, not defects — UAT validates agreed scope, not new scope