Your developers have tested the code. Their automated checks pass, the staging site loads, and the project manager says it is ready. Yet nobody from accounts, the warehouse or customer service has tried to do a normal day's work in the new system. That gap is exactly what user acceptance testing (UAT) is for, and skipping it is one of the most common reasons a launch goes badly.
This guide walks through how to run UAT in a way that is calm, organised and genuinely useful, even if you have never done it before.
What UAT is really checking
Developer testing asks, "Does the software do what we built it to do?" UAT asks a different question: "Does the software let our people do their jobs?" Those are not the same thing. A button can work perfectly and still sit in the wrong place, use confusing wording or skip a step your team relies on.
So UAT is not about finding every technical bug. It is about confirming that real tasks, done by real staff, produce the right result.
Step 1: Agree what "accepted" means before you start
Before anyone logs in, write down the acceptance criteria. These are short, plain statements that describe success. For example:
- A sales rep can create a quote, apply a discount and email it to a customer without help.
- A manager can approve a holiday request from their phone.
- Monthly reports match the totals in the old system for the same period.
Keep the list focused on business outcomes. If a criterion cannot be tested by a non-technical person, rewrite it until it can.
Step 2: Choose the right testers
The best testers are the people who will use the system daily, not senior leaders who will glance at a dashboard once a week. Aim for a mix:
- One or two power users who know every edge case in the current process.
- Someone newer who will spot anything confusing.
- A person from each department that touches the workflow.
Give them protected time. UAT squeezed between other tasks tends to become a rushed click-through that misses the important stuff.
Step 3: Write scenarios, not scripts
A scenario describes a realistic situation: "A returning customer phones to change the delivery address on an order that has already been packed." The tester then works out how to do it. This reveals far more than a rigid script that says "click here, then here", because it tests whether the flow makes sense on its own.
Include the awkward cases too. Think about refunds, partial payments, duplicate records, missing data and users with limited permissions. These are where most real problems hide.
Step 4: Prepare a realistic test environment
Testers need a copy of the system that behaves like the live one, with sensible sample data. Empty databases make it impossible to judge search, reporting or performance. If you can safely use anonymised copies of real records, do it. Make sure everyone has working logins before the first session, because access problems waste the opening day more often than anything else.
Step 5: Make reporting issues easy
Give testers one simple place to log what they find, whether that is a shared tracker or a form. Each report should capture:
- What they were trying to do.
- What they expected to happen.
- What actually happened, ideally with a screenshot.
- How much it blocks their work.
Ask testers to separate genuine defects from wishes. "The total is wrong" is a defect. "It would be nice if this column were wider" is a suggestion for later. Both are valuable, but they should not be treated the same way.
Step 6: Triage daily and retest fixes
Hold a short daily review with the development lead. Sort each issue into must fix before launch, can fix after launch, or not a problem. When fixes come back, the original tester should confirm them, since they know exactly what went wrong the first time.
Step 7: Sign off with confidence
Once every must-fix item is resolved and the acceptance criteria are met, get a named person from the business to formally approve the release. That signature matters. It confirms the people who own the process are satisfied, not just the people who wrote the code.
If you are building a new platform with us, UAT is planned into our software development process from the start rather than bolted on at the end.
FAQ
How long should user acceptance testing take?
It depends on the size of the system and how many workflows it covers. A small internal tool may need a few days, while a platform that replaces several processes could need a few weeks. Plan for at least one round of fixes and retesting.
Can the development agency run UAT for us?
They can organise it, prepare the environment and fix issues, but the testing itself should be done by your own staff. Only they can judge whether the software fits the way your business works.
What if testers keep finding new requirements?
Log them, thank the tester and park them in a separate list. Unless something is essential for launch, treat it as a future improvement so the release does not slip indefinitely.
Next step
If you want a launch that your team trusts from day one, Export Apps can help you plan testing alongside the build. Get in touch with us to talk through your project.