User Acceptance Test Plan Template
UAT plan: objectives, scope, participants, schedule, environment, entry and exit criteria, business scenarios, triage, sign-off
Mode d'emploi: Use it when business users must accept a release before go-live. Agree exit criteria and the sign-off authority first, then write scenarios in business language. The main pitfall is turning UAT into a second system test run by the test team.
Aperçu
User Acceptance Test Plan: [Project or release name]
User Acceptance Test (UAT) plan. Business users confirm that the delivered system supports their real work before it goes live. Based on common industry practice for acceptance testing. Replace every
[bracketed]value and every row marked Example.
| Field | Value |
|---|---|
| Document ID | [UAT-PROJECT-001] |
| Project / release | [Project name] [release] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Closed] |
| UAT lead | [@uat-lead] |
| Business owner (sign-off authority) | [@business-owner] |
| UAT window | YYYY-MM-DD to YYYY-MM-DD |
| Related documents | [Test plan], [Business requirements], [Release plan], [Training material] |
| Last updated | YYYY-MM-DD |
1. Objectives
- Confirm that the [new order management screens] support the end-to-end business processes listed in section 7 without workarounds.
- Confirm that outputs (invoices, reports, notifications) are correct and usable by the receiving teams.
- Confirm that users with the roles in section 3 can complete their tasks after the planned training.
- Obtain formal acceptance from the business owner, or a documented list of conditions for go-live.
2. Scope
| In scope | Out of scope (reason) |
|---|---|
| Example: Order entry, amendment and cancellation | Data migration validation (separate reconciliation activity) |
| Example: Refunds and partial refunds | Performance (covered by performance testing) |
| Example: Daily sales report and export | Mobile app (next release) |
| Example: Role-based access for store staff and managers | Integration error handling (system test) |
3. Participants and roles
| Name | Business role | UAT role | Scenarios | Time allocated |
|---|---|---|---|---|
| [@name] | Head of customer service | Business owner, signs off | Review only | 2 h per week |
| [@name] | Customer service agent | Tester | UAT-01 to UAT-06 | 50% during window |
| [@name] | Store manager | Tester | UAT-07 to UAT-10 | 30% during window |
| [@name] | Finance analyst | Tester | UAT-11, UAT-12 | 2 days |
| [@name] | QA engineer | UAT facilitator, defect logging support | All | 100% |
| [@name] | Product owner | Triage decisions, clarifications | All | On call |
4. Schedule
| Activity | Start | End | Owner |
|---|---|---|---|
| UAT plan approved | YYYY-MM-DD | YYYY-MM-DD | UAT lead |
| Scenarios and data prepared | YYYY-MM-DD | YYYY-MM-DD | UAT lead, testers |
| Tester training (2 h) | YYYY-MM-DD | YYYY-MM-DD | Product owner |
| UAT cycle 1 | YYYY-MM-DD | YYYY-MM-DD | Testers |
| Fix and retest | YYYY-MM-DD | YYYY-MM-DD | Development, testers |
| Sign-off meeting | YYYY-MM-DD | YYYY-MM-DD | Business owner |
5. Environment and data
| Item | Value |
|---|---|
| URL | [https://uat.example.test] |
| Build | [Release candidate version] |
| Accounts | One account per tester with their production role; requested by YYYY-MM-DD |
| Data | [Anonymised copy of production from YYYY-MM-DD, plus seeded test orders] |
| Integrations | [Payment sandbox; email to test mailbox [email protected]] |
| Known differences from production | [Nightly batch runs at 13:00 instead of 02:00] |
| Support channel | [Chat channel #uat-orders, staffed 09:00-17:00] |
6. Entry and exit criteria
6.1 Entry criteria
- System test exit report issued with no open severity-1 defects.
- UAT environment deployed with the release candidate and smoke-tested.
- Test accounts and data ready; testers trained.
- Known-issues list shared with testers.
6.2 Exit criteria
- All scenarios executed; at least 95% passed.
- No open severity-1 or severity-2 defects, unless the business owner accepts a documented workaround.
- All severity-3 defects have an agreed fix release.
- Business owner has signed section 9.
7. Scenarios
| ID | Business scenario | Role | Expected outcome | Priority | Result | Defects |
|---|---|---|---|---|---|---|
| UAT-01 | Example: Take a phone order for a new customer with two items and express delivery | Agent | Order created, confirmation email received, delivery date shown correctly | High | [Pass / Fail] | |
| UAT-02 | Example: Change delivery address on an order not yet shipped | Agent | Address updated; warehouse pick list shows new address | High | ||
| UAT-03 | Example: Issue a partial refund for one damaged item | Agent | Refund amount correct incl. tax; customer notified; finance report shows refund | High | ||
| UAT-04 | Example: Cancel an order after payment | Agent | Full refund issued; stock released | High | ||
| UAT-07 | Example: Store manager approves a refund above 200 EUR | Manager | Approval required and recorded; agent cannot bypass | High | ||
| UAT-11 | Example: Run the daily sales report and reconcile with payment provider statement | Finance | Totals match to the cent | High | ||
| [UAT-nn] | [Scenario] | [Role] | [Outcome] | [High / Medium / Low] |
8. Defect triage
How to report: use the "UAT defect" form in [tool], with scenario ID, what you did, what you expected, what happened and a screenshot.
| Severity | Meaning for users | Target response |
|---|---|---|
| 1 Critical | I cannot do my job and there is no way around it | Fix or decision within 1 business day |
| 2 Major | I can do it only with a painful workaround | Fix within the UAT window |
| 3 Minor | It works but is awkward or slightly wrong | Planned for a later release if not fixed now |
| 4 Cosmetic | Text, layout or spelling | Backlog |
Triage meeting: daily at [10:00] during UAT with the UAT lead, product owner and a developer lead. Outcomes: fix now, fix later, change request (new requirement, not a defect), or not a defect (explained to the tester).
9. Sign-off
| Item | Value |
|---|---|
| Scenarios executed / passed | [n / n] |
| Open defects by severity (1 / 2 / 3 / 4) | [0 / 0 / n / n] |
| Accepted workarounds | [Defect ID: workaround] |
| Conditions for go-live | [Condition, owner, due date] |
Decision: [Accepted / Accepted with conditions / Not accepted]
| Role | Name | Decision | Signature or approval reference | Date |
|---|---|---|---|---|
| Business owner | [@name] | [Decision] | [Reference] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | [Reference] | YYYY-MM-DD |
| UAT lead | [@name] | [Confirmed results] | [Reference] | YYYY-MM-DD |
Standard and licence note
Based on common industry practice for user acceptance testing. This template is original text written for this collection. Template licence: MIT.
Modèles associés
Performance Test Plan and Report Template
Performance plan and report: SLAs, workload mix, Little's law sizing, load, stress, soak and spike tests, percentiles, bottlenecks
Tests & QualitéSoftware Configuration Management Plan Template (IEEE 828)
SCM plan: configuration items, naming, baselines, branching, change control and CCB, status accounting, audits, releases
Tests & QualitéSoftware Quality Assurance Plan Template (IEEE 730)
SQA plan: organisation and independence, product and process assurance, reviews and audits, corrective action, suppliers, metrics