A few weeks before launch, the development team announces that the software is ready for user acceptance testing. For many business owners, this is the first time their team uses the system seriously. What happens next has a big influence on whether launch goes smoothly or turns into weeks of frustration. Good UAT finds the problems that matter while they are still cheap to fix and builds users' confidence. Poor UAT — a quick look, a few clicks, a signature — passes problems straight into live operations.
This guide explains how to plan and run UAT from the business side, even if you have never done it before.
What UAT is — and what it is not
By the time software reaches UAT, the development team should already have tested it: automated tests for logic, functional testing of each feature, checks on different browsers and devices. UAT is not a repeat of that work. Its purpose is to answer three questions from the business's point of view:
- Does it support our real work? Not just the main flow, but the exceptions we deal with every week.
- Does it produce correct results with our data? Prices, quantities, taxes, stock, schedules, reports.
- Can our people use it? At the speed and in the conditions they actually work.
UAT is also the moment the business formally decides whether to accept the release. That decision should be based on evidence, not on pressure from a launch date.
Plan UAT before development finishes
UAT planning should start when development starts. Decide early:
- Who will test — named people from each role, with time blocked in their calendars.
- When — dates for UAT, re-testing and the acceptance decision, with buffer before launch.
- Where — a test environment separate from live data, accessible on the devices people will really use.
- What data — realistic data, ideally a copy of real customers, products and transactions prepared for testing.
- How issues are reported — one shared place, not emails and WhatsApp messages.
- What "accepted" means — the criteria for going live.
The single most common UAT problem is that testers have no time. Their normal work continues, and testing happens in snatched minutes. Block real time — even two hours a day for the testing period — and make it a priority.
Write scenarios from real work
A scenario is a short story of real work that the system must support, with an expected outcome. Good scenarios come from your team's experience, especially the awkward cases. For each process, write:
- The normal case.
- Variations that happen weekly.
- Exceptions that happen monthly but cause trouble.
- Mistakes people make and how they are corrected.
Example scenarios for an order-to-delivery process
| # | Scenario | Expected outcome |
|---|---|---|
| 1 | Regular customer orders three standard items at list price. | Order created, stock reserved, confirmation sent, correct totals and tax. |
| 2 | Customer with a special price agreement orders items at agreed prices. | Agreed prices applied automatically; no manual override needed. |
| 3 | Salesperson offers a discount above their limit. | Order goes to manager for approval; cannot be confirmed until approved. |
| 4 | Customer changes quantity after confirmation. | Revision recorded, stock reservation updated, revised confirmation sent. |
| 5 | Only part of the order is in stock. | Partial dispatch possible; balance stays open with expected date. |
| 6 | Customer is over their credit limit. | Order blocked for dispatch; accounts notified. |
| 7 | Customer returns damaged goods. | Return recorded, stock moved to damaged location, credit note raised. |
| 8 | Order cancelled after picking started. | Picked items returned to stock; documents cancelled correctly. |
Twenty to fifty scenarios for a focused release is common. They become a reusable asset: the same scenarios are run again for future releases.
Prepare realistic data
Testing with a handful of invented records hides problems. Use realistic data: real customers (anonymised if needed), your actual product list and price structures, real stock levels, typical and extreme order sizes, long names and addresses, special characters, multiple branches. If data migration is part of the project, UAT is also the best moment to test migrated data — users quickly spot customers with missing addresses or products with wrong units.
Test in real conditions
Software that works perfectly on a large office monitor may struggle elsewhere. Test where and how people really work:
- Technician apps on the phones technicians actually carry, in basements and plant rooms with weak signal.
- Shop-floor screens on the tablets at the machines, with gloves, noise and interruptions.
- Coordinator screens at the real speed of a busy morning — try entering fifteen jobs in a row.
- Reports with a full month's data, not ten records.
- Printing and PDFs on the printers and paper sizes you use.
Running UAT sessions
A practical rhythm:
- Kick-off — a short session explaining the scope of the release, how to report issues and the timeline.
- Guided sessions — testers work through scenarios, ideally together for the first day, with a member of the development team available to answer questions.
- Free use — testers try their normal daily work in the system, beyond the written scenarios.
- Daily triage — a short daily review of new issues with the development team, classifying and prioritising them.
- Re-testing — fixed issues are re-tested by the person who reported them.
Watching users during the first sessions is valuable. Where they hesitate, click the wrong button or ask "what does this mean?", there is something to improve — even if nothing is technically broken.
Reporting issues well
A good issue report saves hours. Ask testers to include:
- What they were trying to do (the scenario).
- Steps they took.
- What they expected.
- What actually happened.
- A screenshot or screen recording.
- The record involved (order number, customer, job).
"The order screen doesn't work" is hard to act on. "When I add a customer with a special price agreement and then add item X, the list price is shown instead of the agreed price — order SO-1043, screenshot attached" can be fixed quickly.
Classifying issues
| Severity | Meaning | Typical decision |
|---|---|---|
| Critical | Work cannot be done, or results are wrong in ways that cause financial, legal or safety problems. | Must be fixed before launch. |
| Major | Important function fails, but a temporary workaround exists. | Usually fixed before launch; sometimes accepted with a workaround and a firm fix date. |
| Minor | Inconvenience, cosmetic problem or unclear wording. | Can follow after launch. |
| Change request | Works as agreed, but the business now wants something different or new. | Prioritised in the backlog; not a defect. |
Separating defects from change requests is important. Both are legitimate, but they lead to different decisions and, often, different commercial treatment.
Deciding when the software is ready
Agree acceptance criteria in advance, for example:
- All critical scenarios pass.
- No open critical issues; major issues either fixed or accepted with agreed workarounds and dates.
- Key figures — totals, stock, tax, balances — match expected results for test cases.
- Users from each role confirm they can do their daily work.
- Migrated data has been validated by the business.
- Training materials are ready and support for launch is arranged.
When the criteria are met, accept the release formally. When they are not, delaying launch by a week or two is almost always cheaper than launching with known critical problems.
Common traps
- UAT squeezed into the last days because development ran late, with the launch date fixed.
- Only managers test, and daily users meet the system for the first time on launch day.
- Testing with toy data that hides real-world problems.
- Issues reported in scattered messages, so some are lost.
- New ideas mixed with defects, making it impossible to decide readiness.
- Acceptance signed under pressure despite known critical issues.
Example
A service company preparing to launch a new job management system planned UAT for three weeks. Two coordinators, four technicians, the store keeper and an accounts executive were each given two hours a day. The team wrote 34 scenarios, including offline job closure, partial parts usage, a job reassigned mid-day and an AMC customer calling about a non-covered fault. Technicians tested on their own phones in the depot basement. The first week found 41 issues: three critical (one tax calculation, one sync conflict, one permission gap), eleven major and the rest minor, plus nine change requests. Critical and major issues were fixed and re-tested in the second week; the third week was used for a full rehearsal with migrated data. Launch went smoothly, and the change requests formed the core of the next release.
Summary
User acceptance testing is the business's chance to confirm that new software works for its real processes, data, people and conditions. Plan it early, give testers real time, write scenarios from real work including exceptions, use realistic data and devices, report issues clearly, separate defects from change requests and accept the software only against agreed criteria. A few weeks of disciplined UAT is the best insurance for a calm launch.
The development team's role during UAT
UAT is led by the business, but the development team has important responsibilities: preparing a stable test environment with realistic data, briefing testers on the scope of the release, being available to answer questions quickly, joining the daily triage, fixing issues promptly and deploying fixes in planned batches so testers know what to re-test. A development team that disappears during UAT, or deploys changes without warning in the middle of a test session, makes the business's job much harder.
Testing mobile and offline features
Mobile apps used in the field need extra attention. Include scenarios where the phone loses signal in the middle of a task, where two people update the same record while one is offline, where the app is closed and reopened, and where photos and signatures are captured with low storage or a weak battery. Test on the oldest and cheapest phones your team actually uses, not only on the latest models. Check that data entered offline appears correctly in the office system after synchronisation, with the original times preserved.
UAT for later releases
After the first launch, every new release also needs acceptance — but on a smaller scale. Keep your scenario list and re-run the critical ones for each release, because changes in one area can affect another. This is called regression testing. Over time, the development team should automate many of these checks, so your testers can focus on new features and on how the software feels to use. A short, disciplined UAT for each release is far cheaper than discovering a broken invoice calculation from an unhappy customer.
Frequently asked questions
Isn't testing the developer's job?
Developers and testers check that the software works as specified. User acceptance testing checks something different: whether the software works for your business, with your data, your exceptions and your people. Only your team can do that.
How long should UAT take?
It depends on the size of the release. For a focused business application, one to three weeks is common, including time to fix issues and re-test. Rushing UAT into a few days before launch is a common cause of painful go-lives.
Who should take part in UAT?
People who will use the system daily, from every role — not only managers. Include at least one experienced person who knows the exceptions and one newer person who will reveal where the software is confusing.
Do we need to fix every issue before launch?
No. Classify issues by severity. Critical and major issues that stop work or produce wrong results must be fixed; minor issues can often follow shortly after launch, by agreement.
What if users ask for new features during UAT?
Record them separately from defects. Some may be essential and must be prioritised; most can join the backlog for a later release. Mixing new requests with defects confuses the decision about readiness.
