UAT test plan template

Published 19 October 2026

A UAT test plan says how the people who will use the software, or who paid for it, will check that it does what was agreed: what they test, against which version of the requirements, who tests, where, when, and what counts as passing. Below is a free template, a test case and test script template with examples, entry and exit criteria, a readiness checklist, and how UAT differs from SIT and QA.

UAT exists precisely because there are things — business process nuances, legacy configurations, tribal knowledge about why the client’s data looks the way it does — that nobody but the client can fully validate.

— r/ProductManagement, September 2026

What goes in a UAT test plan

1. What is being tested: the release, the build, and the version of the requirements it is tested against — with the change requests approved since.
2. Scope: the business processes and requirements in, and what is out.
3. Testers: who tests what, and who decides on defects.
4. Schedule: when testing starts and ends, and when retests happen.
5. Environment and data: where testing happens, and the data it needs.
6. Entry criteria: what must be true before UAT starts.
7. Test cases: the scenarios, linked to the requirements they check.
8. Defects: how they are logged, ranked and decided.
9. Exit criteria: what must be true to sign off.
10. Sign-off: who signs, and on what.

UAT test plan template

Copy it into Word, Google Docs or Confluence. Square brackets are yours to fill in.

UAT TEST PLAN

Project:       [project name]
Release:       [release name], build [n]
Tested against: [requirements document],
               version [x.y], plus change
               requests [CR-n]
Version:       [x.y] of this plan, [date]
Owner:         [name, role]

1. SCOPE
   In:   [business processes,
         requirements]
   Out:  [what UAT does not cover, and
         why]

2. TESTERS
   [name, role]:  [processes or test
                  cases]
   Decides on defects:  [name, role]

3. SCHEDULE
   Kick-off and training: [date]
   Testing:               [date] to [date]
   Retest window:         [date] to [date]
   Sign-off by:           [date]

4. ENVIRONMENT AND DATA
   Environment:  [URL or system]
   Test data:    [what exists, who
                 prepares it]
   Access:       [accounts, roles, how to
                 get them]

5. ENTRY CRITERIA
   [ ] System and integration testing
       passed
   [ ] No open critical defects
   [ ] Environment and data ready,
       accounts working
   [ ] Test cases reviewed by the business
   [ ] Testers trained and their time
       booked

6. TEST CASES
   [link to the test case sheet]

7. DEFECTS
   Logged in:  [tool]
   Severity:   critical / high / medium /
               low
   Triage:     [who, how often]
   A request for something the
   requirements do not say is a change
   request, not a defect.

8. EXIT CRITERIA
   [ ] Every planned test case run,
       results recorded
   [ ] No open critical or high defects
   [ ] Other open defects accepted in
       writing
   [ ] Every approved change request
       tested

9. SIGN-OFF
   [name, role]:  [decision, date]

The exit criteria are what the UAT sign-off checks; that page has the sign-off document and the email that asks for it.

UAT test case template

One row per scenario, in the business’s words; the fuller format the delivery team uses is on the test case template page. It copies into Excel or Google Sheets as it is:

The Requirement column is what lets you say what was tested against what — and, when a requirement changes, which test cases to run again. A traceability matrix keeps that link across the project.

UAT test script template

A test script is one test case written out step by step, for a tester who has not seen the system before:

TEST SCRIPT UAT-01
Pay an open invoice by card

Requirements:  FR-014, FR-015
Tester:  [name]
Data:    test customer account A;
         invoice INV-2041, 1,250.00 EUR

1. Sign in as the finance clerk.
   Expected: the overview shows 3 open
   invoices.
2. Open INV-2041; choose "Pay by card".
   Expected: the card form shows
   1,250.00 EUR.
3. Pay with the test card ending 4242.
   Expected: "Payment received";
   INV-2041 shows "Paid".
4. Check the clerk's inbox.
   Expected: a receipt for INV-2041.

Result:  [pass / fail]
Defect:  [DEF-n]
Notes:   [   ]

Write test cases in the business’s words. A UAT test case follows a task as the user does it — “pay this month’s invoices” — not a field or a screen. Base each one on an acceptance criterion or a path through a use case, and add the cases only the business knows about: the odd customer, the month-end rush, the legacy data.

UAT entry and exit criteria

Entry criteria stop UAT from starting on software that is not ready, which wastes the testers’ time and their trust:

• System and integration testing are complete, with results.
• No open critical defects; the known open ones are listed.
• The environment works, with realistic data and accounts for every tester.
• The test cases have been reviewed by the business.
• The testers are trained and their time is booked.

Exit criteria say when to stop and sign off — every planned case run, no open critical or high-severity defects, the rest accepted in writing. They are listed in full on the UAT sign-off page. Agree both before testing starts.

UAT process, step by step

1. Plan: scope, testers, dates, environment — the template above.
2. Prepare: test cases, scripts and data; accounts for every tester.
3. Kick off: walk the testers through the system, the cases and how to log a defect.
4. Test: testers run the cases and record results.
5. Triage: daily, decide each defect — fix now, fix later, or not a defect. A request for something the requirements do not say is a change request.
6. Retest the fixes, and anything they touch.
7. Sign off when the exit criteria are met.

How long it takes varies. One team describes theirs: “We do “formal” UAT with the client at least a month before we plan to release a new feature, and we try to limit the UAT period to one week. We give them test cases and release notes to support their testing” (r/ProductManagement, 2024).

Who does UAT?

The people who will use the software, or the client who is paying for it — not the team that built it. Someone on the delivery side — a business analyst, product owner or project manager — plans it and runs the sessions.

Getting the testers to turn up is not a given. Someone who runs a product team for a large ERP described their UAT team’s job as “Facilitating a UAT where business users are encouraged to test themselves, and submit bugs. Participation has always been a big issue. Historically, my PMs have participated more than the stakeholders” (r/ProductManagement, 2024).

What helps: book the testers’ time with their managers in advance, give each one a short list of cases in their own area, and keep the window short.

UAT vs SIT vs QA

UAT readiness checklist

• The plan names the requirements version, with change requests, being tested.
• Every test case points to a requirement, and every requirement in scope has a test case.
• Entry criteria are met, and written down as met.
• Testers are named, trained and booked; each has an account that works.
• Test data looks like real data, including the awkward cases.
• Everyone knows where to log a defect, and who decides on it.
• Exit criteria and the people who sign are agreed in advance.

Where Specroot fits

This is the problem Specroot works on: testing tied to the version of the requirements that was signed off, so that each test case points to what it checks, and a change shows which tests to run again. Specroot for agencies and consultancies.