User Acceptance Testing (UAT) is the final testing phase where actual users or stakeholders verify that the software meets their business requirements and is ready for production.
UAT in Simple Terms
All other testing answers "Does the software work correctly?" UAT answers a different question: "Does the software do what the business actually needs?"
It's the handshake between the QA team and the business — the moment when users confirm the software solves their problem.
Who Performs UAT?
- Business users: People who will use the software daily
- Product owners: Who defined the requirements
- Subject matter experts: Who understand the domain
- Key stakeholders: Who approve the release
Not QA engineers — though QA often facilitates and supports UAT.
Types of UAT
Alpha Testing Internal users test in a controlled environment (developer's site). Early feedback, rough edges expected.
Beta Testing External users test in their own environment. Real-world conditions, broader feedback.
Contract Acceptance Testing Verifying software meets the acceptance criteria defined in the contract.
Regulation Acceptance Testing Ensuring software complies with regulations (healthcare, finance, government).
Operational Acceptance Testing Verifying the software is ready for operations — backup/restore, disaster recovery, maintenance procedures.
How to Plan UAT
1. Define Acceptance Criteria Before development begins, define clear, measurable criteria: - "Users can complete a purchase in under 3 clicks" - "Report generation takes less than 5 seconds" - "All required fields validate before submission"
2. Prepare Test Scenarios Write UAT scenarios in business language, not technical language: - "As a sales manager, I can generate a monthly revenue report" - "As a customer, I can return an item and receive a refund"
3. Set Up Test Environment - Mirror production as closely as possible - Load realistic test data - Ensure all integrations are connected
4. Train UAT Participants - Brief users on the testing process - Provide documentation and support - Set clear expectations for feedback format
5. Execute and Collect Feedback - Users follow scenarios and report issues - Categorize feedback: bug, enhancement, question - Track completion status
6. Sign Off - Review all issues found - Decide: Go, No-Go, or Conditional Go - Get formal acceptance from stakeholders
UAT vs System Testing
| Aspect | System Testing | UAT | |--------|---------------|-----| | Who | QA team | Business users | | Focus | Technical correctness | Business value | | Environment | Test environment | Production-like | | Scripts | Detailed test cases | Business scenarios | | Language | Technical | Business | | Outcome | Bug reports | Go/No-Go decision |
Common UAT Challenges
- Users too busy to dedicate time to testing
- Scope creep — users request new features during UAT
- Unclear criteria — "it doesn't feel right" isn't actionable feedback
- Insufficient test data — users need realistic data to test effectively
- Late UAT — leaving UAT to the last minute limits time to fix issues
UAT Best Practices
- Start UAT early — involve users in Sprint reviews, not just at the end
- Provide test plan templates adapted for business users
- Have QA support available during UAT sessions
- Document everything — UAT feedback is valuable product insight
- Set realistic timelines — rushed UAT leads to missed issues
UAT is a critical skill for QA leaders and is covered in the ISTQB syllabus. Understanding it demonstrates maturity beyond just "finding bugs."