How to write UAT test scripts that business users can actually run
The shape of a UAT script step
- Set-up and test data
- One action to take
- Expected result, in plain words
- Pass or fail, with evidence
User acceptance testing fails more often from badly written scripts than from bad software. A tester from the operations team sits down with a script written by a BA or test analyst, hits step 6 ("verify the ledger posting is correct"), and has no idea what a correct posting looks like. They tick it, or they stop and ask for help. Either way you have lost the point of UAT, which is to find out whether the business can use the change.
This article covers how to write scripts that people outside the project can run alone, with a sample script you can adapt.
Last reviewed: October 2026.
Who the script is for
Write for the least technical person who will run it, and for someone who has never seen the system in test. The business user knows the work. They do not know your test environment, your test data or your abbreviations.
Before writing anything, ask three things. Who will run these scripts? How much time will they have? Will you be there? Scripts that rely on you being in the room are demonstrations, not tests.
One script, one outcome
A good script has a single purpose that you can state in a sentence: "Confirm that a supervisor can release a held payment." If you need the word "and" in that sentence, split it. Short scripts are easier to run, easier to repeat after a fix, and easier to report on.
Starter, £30 (41 files, discovery to a tested set of requirements) · Complete, £80 (59 files, adds governance and assurance). Prices include UK VAT: Starter £25 + VAT, Complete £66.67 + VAT. Payhip may show the price before VAT. One payment, no subscription.
Sold by Quantum Sphere Consulting Limited; your statutory rights apply.The parts every script needs
Reference and title. UAT-014, "Supervisor releases a held payment". The ID matters because defects and the traceability matrix point back to it.
Linked requirement. Tell the tester what the script is checking, in business language, and give the requirement ID for your own records.
Preconditions. Which user ID to log in with, which role it holds, which environment to use, and what data must already exist. Name the specific test record, such as "payment reference TEST-0412 in Held status". If the tester has to create their own data, say how.
Steps. One action each, written as an instruction. Use the words that appear on screen. If the button says "Release payment", write that, not "submit".
Expected result per step. Say what the tester should see, with enough detail that they can tell pass from fail. "Status changes to Released" can be checked. "Works correctly" cannot.
Result, evidence and comments. Pass or fail, a screenshot reference where needed, and room to describe what happened.
A sample script
UAT-014: Supervisor releases a held payment Linked requirement: REQ-06, a supervisor can release a held payment. Environment: UAT. User: SUPERVISOR-TEST1 (role: Payments Supervisor). Data: payment reference TEST-0412, amount £12,500.00, status Held.
| Step | Action | Expected result | Actual result | Pass / Fail |
|---|---|---|---|---|
| 1 | Log in as SUPERVISOR-TEST1 | The Payments home screen appears with a "Held payments" tile showing at least 1 | ||
| 2 | Select the "Held payments" tile | A list opens, including TEST-0412 with status Held | ||
| 3 | Select TEST-0412 | The detail screen shows amount £12,500.00 and the reason for the hold | ||
| 4 | Select "Release payment" | A confirmation box asks "Release this payment?" | ||
| 5 | Select "Yes" | The status changes to Released and a message shows "Payment released" | ||
| 6 | Log out, log in as OPS-TEST2 (role: Payments Operator) and search for TEST-0412 | The status is Released and the audit note shows SUPERVISOR-TEST1 as the person who released it |
Tester name: ____ Date: ____ Overall result: ____
Look at step 6. It checks something the business cares about, who released the payment, and it names the exact user to look for. A step like "check audit trail" would send the tester hunting.
Include a negative case
Business users instinctively test the happy path. Add a script, or a branch, for what must not happen. For the same feature: "Log in as OPS-TEST2 and confirm there is no 'Release payment' button on TEST-0412." Many serious defects are in permissions, and a user who is told to try something that should be blocked will find them.
Test data and environments
Most UAT delays come from data. Before handing over scripts, check each precondition exists in the test environment today, not as a plan. Run each script yourself once. If you cannot finish it in the time you expect a tester to need, it is too long.
Plan for refreshing data. A script that consumes TEST-0412 cannot be run again until the status is reset, and you will almost certainly need to rerun it after a fix.
Defects and sign-off
Give testers one place to log a defect and tell them what to include: script ID, step number, what they expected, what happened, and a screenshot. Agree beforehand who triages defects and how severity is set, so the tester is not left waiting.
For sign-off, make the rule clear in advance: which severities block go-live, and who decides. That is a business decision and belongs in the UAT plan, not in an email on the last day.
A short checklist before you hand scripts over
- Every step is one action.
- Screen wording matches the screen.
- Every expected result can be checked by someone who has not seen the design.
- Preconditions name real users and real test records.
- There is at least one negative case.
- You have run each script once yourself.
- The tester knows who to contact and how to log a defect.
What to do next
Take one script you have already written and give it to a colleague outside the project, without explaining it. Watch where they hesitate. Each pause is a sentence to rewrite.
The free practice case on the site includes expected-outcome examples to work from.