Igor Yussupov
A UAT test plan answers four questions before anyone opens the staging site: what are we accepting, who decides, what counts as done, and what happens to the defects people find. Most plans are good at the first two and skip the last two, which is where acceptance rounds stall. Below is a template you can copy, and notes on how to fill in each part.
What a UAT test plan is, and is not
A QA test plan checks that the software was built to the specification. A UAT test plan checks that the people who will use it can do their actual work with it. That changes who writes it and how it reads: it is owned by the business side, written in the words of the business, and short enough that a tester with a day job will read it.
It is also not the test cases themselves, and it is not the sign-off record. It is the page that says what the round covers, who takes part, and the rules for finishing. If you want the wider picture of how UAT fits into a release, start with the complete UAT guide.
The nine sections
| Section | What goes in it | Usually filled in by |
|---|---|---|
| 1. Objective and scope | What is being accepted, which release, and what is out of scope. | Project or product owner |
| 2. Entry criteria | What must be true before UAT starts. | QA lead with the project owner |
| 3. People and roles | The approver, the testers, a coordinator, and a developer who answers questions. | Project owner |
| 4. Environment and data | Where testing happens, which accounts and data testers use. | Delivery team |
| 5. Schedule | Start, end, a retest window and the go-live date. | Coordinator |
| 6. Scenarios | The business processes testers walk through, with the expected result. | Business testers with QA |
| 7. Defect process | Where defects are reported, how they are rated, who triages. | QA lead |
| 8. Exit criteria | What must be true for the round to end and the release to proceed. | Approver |
| 9. Sign-off | Who approves, how, and what gets recorded. | Approver |
Copy-paste template
Paste this into a document, a wiki page or a ticket and replace the bracketed parts.
UAT TEST PLAN: [Project] [Release / version]
1. OBJECTIVE AND SCOPE
Objective: Confirm that [business users] can [do the work] with [release].
In scope: [workflows, roles, integrations]
Out of scope: [anything testers should not spend time on]
2. ENTRY CRITERIA
[ ] QA testing finished, no open critical defects
[ ] UAT environment deployed with build [version]
[ ] Test data loaded and accounts created for every tester
[ ] Testers briefed and have time booked
3. PEOPLE AND ROLES
Approver: [name] (decides go or no-go)
Testers: [names and the role each one tests as]
UAT coordinator: [name] (chases testers, runs the daily triage)
Developer on call: [name] (answers questions the same day)
4. ENVIRONMENT AND DATA
URL: [staging address]
Accounts: [where testers find their logins]
Data: [refresh date, what is masked]
Integrations: [live, sandbox or switched off, per integration]
5. SCHEDULE
Briefing: [date]
Testing window: [start] to [end]
Fix and retest: [start] to [end]
Sign-off meeting: [date]
Go-live: [date]
6. SCENARIOS
See the scenario table: ID, scenario, role, expected result, status, defect link.
7. DEFECT PROCESS
Report defects here: [tool or inbox]
Severity levels: [Critical / High / Medium / Low, each with one example]
Triage: [who, how often, outcomes: fix now, fix later, not a defect]
Retest: [the person who reported it confirms the fix]
8. EXIT CRITERIA
[ ] All must-have scenarios executed
[ ] No open Critical or High defects
[ ] Remaining defects listed and accepted by the approver
[ ] Every fixed defect retested
9. SIGN-OFF
Approver: [name] Date: [date] Build: [version]
Accepted known issues: [list]The scenario table
Scenarios are the heart of the plan. Write them as things a person does at work, not as screens in the application. This is an example for an invoicing system; yours will use your own processes.
| ID | Scenario | Role | Expected result | Status | Defect |
|---|---|---|---|---|---|
| INV-01 | Create an invoice for an existing customer and send it | Accounts clerk | Invoice total matches the order, the customer receives the email | Not run | |
| INV-02 | Apply a credit note to an unpaid invoice | Accounts clerk | Balance drops by the credit amount, both documents are linked | Not run | |
| INV-03 | Try to approve your own invoice | Accounts clerk | The system refuses and says why | Not run |
The third row is deliberate. Include the cases where the system should say no: a refused permission, a cancelled order, a wrong entry. Business testers find the most useful defects there, because they know what a real mistake looks like.
Notes on filling it in
Scope: write down what is out
The out-of-scope list prevents the most arguments. If a report screen is not part of this release, say so, or testers will log it as a defect.
Entry criteria: do not start early
UAT run on an environment that is half deployed teaches testers that the plan is optional. Decide the entry criteria, and let the coordinator refuse to start until they are met.
Roles: name one approver
A committee cannot sign off. Name one person who decides, and say who stands in for them. Name a developer who answers questions the same day, because a tester waiting two days for an answer stops testing.
Environment and data: decide what is real
For every integration (payments, email, a CRM), write down whether it is live, in sandbox mode or switched off. Otherwise a round of testing can end up emailing real customers.
Exit criteria: agree them before you see the defects
Thresholds such as "no open Critical or High defects" are examples; pick your own. What matters is that they are agreed before testing starts, while nobody has a favourite bug to defend.
Where the defects go
Section 7 is the one that decides whether the round runs smoothly. Pick one place for defects and tell every tester. Then check that a tester can actually use it: a form that asks for the browser version, the console output and a numbered list of steps will lose most business users.
This is the part SnagRelay handles. A tester clicks Report, points at what is wrong and writes what they expected, and the element, the console errors, the failing requests and the steps are attached. The ticket goes to Jira, Linear, GitHub, GitLab, Trello or Azure DevOps, or waits in the SnagRelay inbox. SnagRelay does not manage test cases or the sign-off: keep the plan, the scenarios and the approval where they are now. See UAT testing with SnagRelay for how a round is set up.
FAQ
How long should a UAT test plan be?
Short enough that testers read it. For most projects that means a few pages plus the scenario table. If testers need a manual to understand the plan, split the detail into the scenarios and keep the plan itself to the nine sections.
Who should write the UAT test plan?
The business side owns it and QA helps. The project owner writes the scope and the exit criteria, QA contributes entry criteria and the defect process, and the business testers write the scenarios, because they know the work.
What is the difference between a UAT test plan and a UAT test case?
The plan covers the whole round: scope, people, schedule and rules. A test case or scenario is one thing a tester does and the result they expect. The plan contains or links to the scenarios.
Can I reuse my QA test plan?
Reuse the structure, not the content. A QA plan lists technical checks against the specification. A UAT plan lists business processes in business language. Copying the technical checks makes testers repeat QA instead of judging whether the system fits the work.
Do I need a separate environment for UAT?
Yes, in almost every case. Testers need a stable, production-like environment that developers are not changing underneath them. Mixed in with development, results cannot be trusted.