A UAT test script is a step-by-step test that a business user follows to prove one real business scenario works in the finished software. It names the role, starting data, steps, expected result and evidence. Scripts are written from the approved scope, run by the people who will use the system, and end in a clear accept or reject decision.
This guide is for owners, product managers and operations leads about to accept a custom build: a web application, customer portal, mobile back-office app or system integration. It works for any custom software built against an approved scope. For ERP-specific scenarios such as procure-to-pay, order-to-cash and period-end close, use our ERP UAT testing plan instead; this guide does not repeat them. If you want an independent QA service to plan and run testing alongside your own acceptance work, see our software quality assurance and testing service.
Key takeaways
- Write scripts from the approved scope and its acceptance criteria, not from screens. Every criterion should trace to at least one script.
- The business owns the UAT plan and the scripts. The delivery team supports with environment, data and fixes, and does not mark scripts as passed.
- Choose business-critical scenarios first: the ones where failure stops revenue, breaks a control or leaves staff unable to work.
- Write happy-path and failure-path scripts. Failure paths find the gaps that hurt most.
- Agree entry and exit criteria before UAT starts, so "done" is not decided under deadline pressure.
- Keep defects (software differs from the approved scope) separate from change requests (the scope was wrong or has changed).
What is a UAT test script?
A UAT test script is a written set of steps that a business user follows to check one real scenario in the finished software, such as approving a purchase request or issuing a refund. It states who performs it, the starting data, each step, the expected result and where to record evidence, so a pass or fail is clear.
The ISTQB glossary describes acceptance testing as a test level focused on deciding whether to accept the system. That is why a script ends in a pass or fail the business can stand behind, rather than a list of observations. Scripts are the evidence behind the final sign-off.
What is a UAT test plan and who creates it?
A UAT test plan is the short document that says what will be accepted, by whom, in which environment, with which data, in what order, by which date and what counts as done. The business owner or product owner is accountable for it. The delivery team supplies the environment, test data and the approved scope it is built from.
| Role | What they typically do in UAT |
|---|
| Business owner or sponsor | Owns the plan, names the signatories, gives final acceptance |
| Process owner or product owner | Chooses business-critical scenarios, reviews scripts, signs for their area |
| Testers (end users) | Run the scripts, record results and evidence |
| Business analyst or QA lead | Drafts scripts from the acceptance criteria and keeps the traceability table |
| Delivery team or vendor | Prepares the environment and data, explains behaviour, fixes defects, does not mark scripts as passed |
A workable plan covers scope, the script list, testers and their availability, environment and data, entry and exit criteria, the defect process, a schedule with at least two cycles, and the sign-off list. Two pages is usually enough.
How is UAT different from QA, system testing and regression testing?
UAT asks whether the business can run its work on the software, and business users answer it. QA and system testing ask whether the software works as built, and the delivery or QA team answers that. Regression testing checks that new changes did not break what already worked. The three overlap, but none replaces the others.
| Test type | Question it answers | Who does it | Based on |
|---|
| Unit and integration testing | Do the parts work and connect? | Developers | Technical design |
| System testing and QA | Does the whole product meet its specification? | QA testers | Specification, requirements |
| Regression testing | Did a change break something that worked? | QA, often automated | Previous passed tests |
| UAT | Can we run our business on this? | End users and process owners | Approved scope, real scenarios |
Do not use UAT to find every bug. If testers spend UAT fighting basic errors, the product was not ready, and the entry criteria below exist to stop that. For how outside QA fits around your own acceptance work, see our QA outsourcing guide.
How do you write UAT scripts from an approved scope?
Start from the approved scope and its acceptance criteria, not from the screens. List each criterion, decide which business scenario proves it, then write one script per scenario with a happy path and at least one failure case. Keep a traceability table so every criterion links to a script and every script links back to a criterion.
| Acceptance criterion (example) | Scenario that proves it | Script ID | Path |
|---|
| A customer can download an invoice for any past order | Customer finds an old order and downloads the invoice | PORTAL-02 | Happy |
| A customer cannot see another customer's orders | Customer edits the order number in the address bar | PORTAL-03 | Failure |
| A refund over the agent's limit needs supervisor approval | Agent refunds an amount above their limit | PORTAL-04 | Failure |
| Stock levels update after an order is shipped | Warehouse ships an order and checks the count | INT-02 | Happy |
Good acceptance criteria are observable (someone can see the result), single-condition, written in business words and tied to data. "The system is fast" cannot be scripted; "the order list opens in a few seconds with the normal data volume" can, once the team agrees the number. If your scope is vague, our software requirements brief template shows how to word requirements so they can be tested.
The table shows gaps (a criterion with no script is untested) and waste (a script with no criterion tests something nobody asked for, or points to a missing requirement).
What are business-critical scenarios for user acceptance testing?
Business-critical scenarios are situations where a failure would stop revenue, break a legal or financial control, harm customers or leave staff unable to do their core job. They are tested first, by experienced users, with realistic data, and a failure blocks launch. Less critical scenarios can be accepted with a workaround.
Score every scenario with five questions. Two or more "yes" answers usually make it business-critical.
- Impact: if it fails, does money, stock or customer data go wrong?
- Frequency: is it done every day, or by many users?
- Control: does it enforce an approval, permission, limit or audit trail?
- No workaround: can the work continue some other way if it fails?
- Reputation or compliance: would customers, regulators or partners notice?
Typical examples in custom software are permissions, the core transaction (order, booking, claim, job), payments and refunds, data exchanged with another system, the report management relies on, and what happens when something goes wrong, such as a rejected payment or a lost connection.
What does a UAT script template look like?
A UAT script template is one table or form per scenario with fixed fields: ID, scenario, role, preconditions, numbered steps, expected result, actual result, evidence, status and defect reference. Fixed fields make scripts easy to review before testing and easy to audit after it, because any reader can see what was tested and what happened.
| Field | What to write |
|---|
| Script ID | Short code by area, for example PORTAL-04 |
| Requirement or criterion | The approved-scope item this script proves |
| Scenario | One sentence in business words |
| Priority | Business-critical, important or minor |
| Role | The user type performing it, not a named person |
| Preconditions | Account, data and environment state needed before step 1 |
| Steps | Numbered, one action each, using real field names |
| Expected result | What the tester should see, including figures where relevant |
| Actual result | Filled in during the test |
| Evidence | Screenshot, document number or exported file |
| Status | Pass, fail or blocked |
| Defect reference | Ticket number if it failed, plus who ran it and when |
Keep each script to one scenario and roughly ten steps or fewer. A script that tries to cover a whole process becomes hard to repeat and hard to diagnose when it fails.
What do UAT test script examples look like for different systems?
Example scripts differ by system type but keep the same fields. A customer portal script checks permissions and money, an integration script checks data moving between systems, and a mobile back-office script checks field conditions such as poor signal. All three below are illustrative and use invented data.
Example 1: customer portal (refund request)
PORTAL-04 | Role: customer service agent | Priority: business-critical | Preconditions: test customer with a delivered order worth 120 in the test data; agent refund limit set to 100.
| Step | Action | Expected result |
|---|
| 1 | Search for the test customer and open the delivered order | Order shows status Delivered and the paid amount |
| 2 | Choose Refund and enter 80 | Refund is accepted and a confirmation reference appears |
| 3 | Open the order history | Refund of 80 is listed with agent name and time |
| 4 | Start a second refund of 120 on the same order | System blocks it or routes it to a supervisor for approval; no money is released |
Example 2: system integration (web order to warehouse system)
INT-02 | Role: warehouse supervisor | Priority: business-critical | Preconditions: test product with a stock of 10 in both systems; test connection to the warehouse system active.
| Step | Action | Expected result |
|---|
| 1 | Place a test order for 3 units on the web application | Order is created with a unique order number |
| 2 | Wait for the sync window and open the warehouse system | The same order appears once, with the right items, address and quantity |
| 3 | Mark the order shipped in the warehouse system | Web order status changes to Shipped |
| 4 | Check stock in both systems | Both show 7 |
| 5 | Resend the same order message from the test tool | No second order is created |
Example 3: mobile back-office app (job completion with poor signal)
MOB-06 | Role: field technician | Priority: business-critical | Preconditions: technician logged in on a test phone with one job assigned; job data downloaded.
| Step | Action | Expected result |
|---|
| 1 | Switch the phone to airplane mode | App shows an offline indicator and keeps the job open |
| 2 | Add notes, two photos and a customer signature, then tap Complete | Job shows Completed, pending upload; nothing is lost |
| 3 | Switch the connection back on | Upload finishes without a manual retry |
| 4 | Open the job in the office web view | Notes, photos and signature are all present, with the correct time |
How many UAT test scripts do you need?
There is no standard number. Plan one script per business scenario, add failure-path scripts for the critical ones, and size the set by the number of approved requirements and the risk of each. For a typical custom application that is commonly tens of scripts rather than hundreds, and fewer for a small tool with few roles.
To size it, group the acceptance criteria into scenarios a user would run in one sitting, add failure-path scripts for the critical ones, time five sample scripts with real testers, then multiply and add time for retesting. Compare the total with the hours testers can actually give per day.
If the total does not fit the testers' real availability, cut low-risk scripts, not business-critical ones. Plan at least two cycles: one to find defects and one to confirm fixes.
What are UAT entry and exit criteria?
Entry criteria are the conditions that must be true before UAT starts. Exit criteria are the conditions that must be true before UAT ends and sign-off can be given. Agreeing both in writing before testing starts prevents two common problems: starting UAT on unfinished software and arguing at the end about what "done" means.
| Entry criteria | Exit criteria |
|---|
| Software | Build deployed to a stable test environment; system testing complete for in-scope features | No open critical defects; high defects fixed or each workaround accepted in writing |
| Scripts | All scripts written, reviewed by the process owner and traced to the approved scope | All business-critical scripts executed with evidence and passed |
| Data | Realistic test data loaded; test accounts exist for each role | Results reproducible on the final build, not an earlier one |
| People | Testers named, trained on the test environment and given time in their calendar | Each signatory has reviewed the open-defect list |
| Process | Defect log and triage routine agreed | Remaining medium and low defects listed with owners and planned fix dates |
What is the difference between a UAT defect and a change request?
A defect is when the software behaves differently from the approved scope. A change request is when it behaves as agreed, but the business now wants something different or the scope missed a need. Defects are fixed within the agreed work; change requests are assessed for effect on scope and schedule and approved before work starts.
| Severity | Meaning | Typical launch rule |
|---|
| Critical | A business-critical scenario cannot be completed, or data or money is wrong, with no workaround | Fix and retest before launch |
| High | The scenario works only through a difficult or risky workaround | Fix before launch, or the process owner accepts the workaround in writing |
| Medium | Inconvenient, with a reasonable workaround | Can launch with a dated fix plan |
| Low | Cosmetic or minor | Schedule after launch |
Three triage questions settle most arguments. Does the approved scope say this should work differently (defect)? Is it working as agreed but the agreement is wrong (change request)? Did the tester expect something nobody ever promised (training or documentation)? Log all three separately. Mixing change requests into the defect list is a common reason UAT never seems to finish.
When does automation help with UAT?
Automation helps UAT by rerunning stable, repetitive checks, such as login, core calculations and the business-critical scenarios, after every fix. That frees testers to spend their time on judgement-heavy scripts. It does not replace business users, because UAT is a human decision about fit. Automate a script only after it has passed manually and the screens have stopped changing.
- Good candidates: login and roles, calculations and totals, integration message checks, validation rules, and business-critical scenarios you will rerun at every release.
- Poor candidates: first-time usability checks, screens still being redesigned, and anything a user must judge by feel.
Treat automated runs as support for the sign-off, not a replacement. Business users should still run the critical scenarios on the final build themselves.
Who signs off UAT, and what does sign-off include?
UAT sign-off is a written decision, given by the business owner and each process owner, that the software meets the approved scope and can go live, with any accepted exceptions listed. The delivery team does not sign for the business. The decision should rest on the exit criteria and on the evidence in the scripts.
A sign-off record should include:
- The build or version number that was tested
- Scripts with status and evidence links
- Open defects by severity, with accepted workarounds
- Change requests raised and what was decided
- Names, roles and dates for each signatory
After launch, accepted low defects and workarounds become the first items in your support backlog; see what software maintenance covers for how to keep that work organised.
Illustrative example
This example is hypothetical; the company and figures are invented. A regional equipment-rental firm has a custom booking portal and a mobile app for delivery drivers built against an approved scope with 46 acceptance criteria. The operations manager owns the UAT plan. A business analyst groups the criteria into 31 scripts and a traceability table, and the process owners mark 9 of them business-critical: booking, deposit payment, damage-fee refund, stock availability, driver proof of delivery, and four permission checks.
In cycle one, 27 scripts pass and 4 fail. One failure is critical: a driver who completes a delivery with no signal loses the signature. It is fixed and retested in cycle two. During testing the finance lead also asks for a new report, which is logged as a change request and scheduled after launch. At sign-off the operations manager and the finance lead sign, with two low defects listed and dated.
When this is the wrong approach
Formal scripted UAT is the wrong approach for a very small internal tool used by a handful of people, or for a prototype whose requirements are still changing every few days. In both cases a short checklist of the key scenarios, run live with the users, costs less and finds the same problems.
It is also the wrong approach when UAT is being used to replace earlier testing or to decide what the product should be. Fix the earlier stage first.
Glossary: UAT, user acceptance testing, the final check by business users that the software supports their real work; acceptance criteria, the conditions a feature must meet to be accepted; test script, a step-by-step test for one scenario; traceability, the link from each requirement to the scripts that prove it; entry criteria, conditions to start testing; exit criteria, conditions to finish and sign off; regression testing, rechecking that existing features still work after a change; change request, a formal request to alter the approved scope.
How Timeline Digital approaches acceptance testing
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, that delivers custom software as managed projects. We start by learning your requirements, then build a free pilot of the 2 to 3 key modules that your team tests with real scenarios before you decide on the final agreement. There is no fixed timeframe: the schedule for a custom software project is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a focused system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Timeline Digital does not publish prices for custom software, because every project is custom. See custom software development to start.