This UAT test plan template is ready to copy into Word or Google Docs. Every section is filled in for an example website launch, so you can see what a finished plan looks like and swap in your own details.

A UAT test plan records what will be tested, who tests it, where, by when, and what counts as a pass. If you want the background first, read our guide to user acceptance testing.

The example is a fictional garden centre called Bramblewick relaunching its online shop. All names, dates and addresses are invented.

Part 1: Plan details

UAT TEST PLANProject: Bramblewick Garden Centre website relaunchVersion: 1.2Author: Priya Shah, Project Manager (agency)Approver: Tom Reed, Marketing Director (client)Date issued: 6 January 20271. PURPOSEConfirm that the new Bramblewick website does what the businessneeds before it replaces the current site on Tuesday 2 February 2027.UAT checks the site against the approved brief (v3, 12 October 2026).It is not a design review. New ideas go on the change log.2. SCOPEIn scope:- Browsing, searching and filtering products- Basket, checkout and card payment (test mode)- Click and collect booking- Customer accounts and password reset- Contact and plant enquiry forms- Order and enquiry emails- CMS tasks: add a product, publish a post, change opening hoursOut of scope:- Load testing (run separately by the developers)- SEO redirects (covered by the migration plan)- Accuracy of stock figures (owned by the warehouse team)- The current website3. ROLESUAT lead: Priya Shah. Runs the round, triage and the daily update.Approver: Tom Reed. Makes the go or no-go decision and signs section 13.Tester: Amy Lowe. Customer journeys on phones.Tester: Ben Cole. Click and collect and shop floor tasks.Tester: Hana Ito. CMS tasks.Developer: Joe Marsh. Fixes, deployments and first-line retests.Backup tester: Ruth Khan. Covers any tester who is unavailable.4. ENVIRONMENT AND ACCESSURL: https://uat.bramblewick.exampleAccess: Password sent separately to named testers.Payments: Gateway in test mode. Test card details are in the kick-off email.Emails: All outgoing email diverted to [email protected]Deployments: One a day at 5pm, agreed by the UAT lead first.Search engines: Blocked by the site password.5. TEST DATA- 40 sample products matching the live catalogue structure- 6 test customer accounts with invented names and emails- 3 test discount codes: UAT10, UATFREE and UATEXPIRED- No real customer data on this environment6. DEVICES AND BROWSERS- Chrome and Edge on Windows 11- Safari on macOS- Safari on iPhone- Chrome on Android- Safari on iPad7. ENTRY CRITERIAUAT starts only when all of these are true:[ ] Internal QA is complete with no open Critical or High issues[ ] The release is deployed to UAT and the version is recorded[ ] Test data and accounts are loaded[ ] Payment test mode and email diversion are confirmed working[ ] Testers have their logins and time booked8. SCHEDULEMon 11 Jan: Plan approvedFri 15 Jan: Entry criteria checked, logins sentMon 18 Jan: Kick-off call at 10am, testing opensWed 20 Jan: Mid-point reviewFri 22 Jan: Testing closes at 5pmMon 25 to Wed 27 Jan: Fixes and retestsThu 28 Jan: Sign-off decisionTue 2 Feb: Go-live at 7am

Part 2: Test cases

Section 9 of the plan is the test case table. Select the table below and paste it straight into Word, Excel or Google Sheets. It keeps its columns.

ID	Scenario	Steps	Expected result	Priority	Tester	Result
UAT-01	Find a product	Search "apple tree", filter by size	Matching products appear and the filter updates the list	Must	Amy
UAT-02	Buy as a guest on a phone	Add a plant to the basket, check out with the test card	Order confirmed, confirmation email arrives	Must	Amy
UAT-03	Declined payment	Check out with the declined test card	Clear error, basket kept, can try again	Must	Amy
UAT-04	Apply a discount	Enter UAT10 in the basket	10% removed, total and VAT correct	Must	Amy
UAT-05	Expired discount	Enter UATEXPIRED in the basket	Polite message, no discount applied	Should	Amy
UAT-06	Click and collect	Choose a collection slot at checkout	Slot shown on confirmation page and email	Must	Ben
UAT-07	Full slot	Try to choose a slot marked full	Slot cannot be selected	Should	Ben
UAT-08	Account and password reset	Register, log out, reset password	Reset email arrives and new password works	Must	Hana
UAT-09	Plant enquiry form	Submit once empty, once complete	Errors shown when empty, enquiry reaches the shop inbox	Must	Ben
UAT-10	Order reaches staff	Place an order, open the order screen	Shop team sees the order with the correct lines	Must	Ben
UAT-11	Add a product	Add a product with image and price in the CMS	Product appears on the site at the right price	Must	Hana
UAT-12	Change opening hours	Edit the hours in the CMS	New hours appear in the footer and on the contact page	Should	Hana
UAT-13	Publish a blog post	Draft, preview, publish	Post appears on the blog and matches the preview	Should	Hana
UAT-14	Tablet browsing	Browse and buy on an iPad	Layout usable, no hidden or overlapping buttons	Should	Amy

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Part 3: Rules and sign-off

10. ISSUE HANDLINGReport every issue in the shared tracker, not by email.Each issue needs the page, steps, expected result, actual result and device.Severity definitions:Critical: blocks a core journey with no workaround. Fix the same working day.High: core journey affected, workaround exists. Fix the next working day.Medium: a real problem that does not stop the task. Fix before go-live if possible.Low: cosmetic or wording. Fix within 30 days of launch.Triage: 4pm daily with Priya, Joe and Tom.New requests go on the change log and are not counted as failures.Testing pauses if checkout, login or payment is unavailable for over 2 hours.11. EXIT CRITERIAUAT ends when all of these are true:[ ] All Must scenarios have been run and passed[ ] At least 90% of Should scenarios have passed[ ] No Critical or High issues are open[ ] Every open Medium or Low issue has an owner and a date[ ] Fixes have been retested by the person who raised them12. RISKSRisk: Testers pulled onto the January stock-take.Action: Hours agreed with line managers. Ruth Khan is the backup tester.Risk: Stock system sandbox unavailable.Action: Joe to confirm on 15 January. If unavailable, UAT-10 becomes amanual check with the warehouse team.Risk: Late design requests threaten the go-live date.Action: Change log only. Tom decides what moves into the next phase.13. SIGN-OFFDecision (tick one):[ ] Accepted[ ] Accepted with conditions (list below)[ ] Not accepted (reasons below)Conditions or reasons:Approver name: Tom ReedSignature:Date:

Using this template in Word or Google Docs

Copy Part 1 and paste it as plain text. In Word, use the Keep Text Only paste option. In Google Docs, press Ctrl+Shift+V.
Select each numbered section title and apply a heading style. Word and Google Docs can then build a contents page and a navigation pane from them.
Copy the test case table from this page and paste it in with its formatting kept. If testers will record results in a spreadsheet, paste it into Excel or Google Sheets instead.
Paste Part 3 as plain text and continue the headings.
Use Find and Replace to swap the example name, people and dates, then read through once more for anything specific to Bramblewick.
Put the version number in the header and update it every time the plan changes.

Scaling it to your project

The example suits a shop with several user journeys. For a small brochure site, keep sections 1, 2, 3, 8, 9, 11 and 13 and cut the rest down to a line each. Aim for 5 to 8 test cases and a test window of two or three days.

For a larger build, split the test cases by journey and give each group its own tester and retest sign-off. Add a section on training if CMS editors will be using the site for the first time.

Who signs what

Keep decisions with one named person each:

Decision	Owner
Plan approved before testing	Approver and UAT lead
Entry criteria met	UAT lead
Severity and fix priority	UAT lead with the developer
Whether an item is a defect or a change	Approver, if disputed
Go or no-go	Approver, using the UAT sign-off template

Common mistakes in UAT test plans

Test cases written from the spec. A tester who reads "validate postcode field" has no idea what to do. Write what a person is trying to achieve, and use plain severity definitions so everyone grades issues the same way.

No out-of-scope list. Without one, testers report things the project was never meant to cover, and every report becomes a debate.

Fix time left off the schedule. The dates in section 8 include three days after testing closes. Without that gap, any fix at all pushes the launch back.

No named backup tester. People get ill and shops get busy. Name a backup and the round survives.

An environment nobody checked. Confirm payment test mode and email diversion before kick-off. Our guide to what a UAT environment needs covers the rest, and the UAT checklist gives you the pre-flight list.

If your testers are reporting through website UAT software such as QualityHive (our product), section 10 gets shorter. Testers click the element and type what is wrong, so the screenshot, the pinned element and the browser details are recorded for them. Guest links and browser details need the Lite plan or above.

Revolutionise your QA processes

Frequently asked questions

What should a UAT test plan include?

At minimum: purpose, scope, roles, environment and access, test data, entry criteria, schedule, test cases, issue handling rules, exit criteria, risks and a sign-off section. The template above covers all of them.

Who writes the UAT test plan?

Usually the project manager or UAT lead, with input from the client on scope and test cases. The approver should agree the plan before testing starts, so the definition of done is settled in advance.

How many test cases do I need?

Cover every must-have requirement and the awkward paths around it. Around 5 to 8 suits a brochure site and 15 to 30 suits a typical online shop. Quality matters more than count.

What is the difference between a test plan and a test case?

The plan covers how the whole round will run. A test case is one task within it, with its own steps and expected result. Section 9 of the template is where the test cases live.