This guide is for anyone responsible for getting a piece of custom software signed off by the business before it goes live, and trying to make UAT something more useful than “the client clicks around for a week and emails complaints”. By the end you will know who should be testing, how to structure the tests so they actually exercise the software, how to triage what comes back, and how to make a defensible call on whether the release is ready to ship.
Who This Guide Is For
Project managers, operations leads, and product owners on the client side of a software project — the people who have to decide whether to accept the work. This applies whether the build is being done by an external partner or an internal team. The principles are the same: UAT is the formal moment where the business confirms that what was built matches what was specified, and missing that moment is expensive.
Before You Start
You should have the original scope or specification to hand. UAT is the comparison between what was built and what was scoped — without the scope as a reference, “acceptance” becomes a feeling rather than a decision. If the scope is vague, the UAT will be vague.
You should also know what environment you are testing in. UAT on a staging environment populated with realistic data is meaningful. UAT on a developer’s laptop with three test records is not — it does not exercise the system under conditions that resemble production.
If the project is at the planning stage and UAT is being designed in, How to Write a Software RFP covers building acceptance criteria into the procurement.
Step 1: Decide Who Actually Tests
The instinct is to invite everyone affected by the system to test it. This produces a flood of comments that are not really UAT — they are wishlists, opinions, and concerns about workflows that were never in scope. UAT is verification, not requirements gathering.
The right testers are: the people who will use the system day-to-day in their real work, the person who owns the specification (so they can confirm fit-for-purpose), and a technical reviewer (so they can flag obvious technical issues). For most internal tools, three to six testers is the right size — large enough to cover the workflows, small enough that feedback can be triaged.
Wider stakeholders — executives, adjacent teams, “anyone who might care” — should be shown the system, but not as part of UAT. Their feedback is valuable for future phases, but it is not the test of whether this phase delivered the scope. Conflating the two is the most common reason UAT drags on for months.
Step 2: Write Test Cases Against the Scope
Each acceptance criterion in the scope should have at least one test case. A test case is a concrete, specific instruction: “Log in as a project manager, create a new project with name X, assign two users to it, set the deadline to two weeks from now, and confirm the project appears on the dashboard with the correct status.”
That kind of specificity matters. A vague test (“check the project creation flow works”) produces vague feedback (“it’s a bit confusing”). A specific test produces a specific result: it worked, it failed in a particular way, or it surfaced an ambiguity that needs resolving.
For a typical internal tool, the test case list runs from twenty to a hundred items. Group them by workflow: project creation, project editing, user management, reporting, exports, integrations. Each test case has an owner (which tester is responsible for it), expected outcome, and pass/fail tick box. A spreadsheet works fine; the format is less important than the discipline.
If writing the test cases is hard, the scope is not specific enough. Use the test case writing as a final scope review — anywhere you struggle to write a concrete test, there is ambiguity in the spec that needs to be resolved before UAT, not during.
Step 3: Run a Pre-UAT Smoke Test
Before opening UAT to the business testers, run a smoke test internally — typically the technical lead and the project manager going through the major flows for thirty minutes to two hours. This catches the obvious breakage that should never reach UAT: a button that does not work, a page that errors on load, an integration that has not been deployed.
The smoke test is not redundant with UAT. UAT is the business confirming the software matches the spec; the smoke test is engineering confirming the software is in a state worth testing at all. Skipping the smoke test wastes the business testers’ time on issues they should never have seen.
A real example. A reporting dashboard release went straight to UAT without a smoke test. The first tester opened the main dashboard and saw an empty page — a deployment issue had reset the data refresh. Six testers wasted a morning before the issue was diagnosed. A fifteen-minute smoke test would have caught it.
Step 4: Define Pass, Fail, and Defer
The hardest part of UAT is deciding what counts as a blocker. Treating every comment as a release-blocker produces UAT cycles that never end. Treating none as blockers produces software that ships broken.
The framework that works is three categories:
- Pass: the test case worked as specified. Move on.
- Fail – blocker: the system did not do what the scope said it should do, and it is significant enough that the release cannot go ahead until it is fixed. Examples: a core workflow is broken, data is being saved incorrectly, an integration is not working.
- Fail – defer: the system did not match the spec, but the discrepancy is minor enough to live with, or it is genuinely out of scope and is a wishlist item for the next phase. Document it; do not block on it.
The triage of fail – blocker versus fail – defer is the most important call. The principle: a blocker is something where the business cannot use the software for its intended purpose. Cosmetic issues, minor UX preferences, edge cases that affect 1% of users — these are usually defer, even if they feel annoying. Things that prevent the system being used for its core job are always blocker.
Document every defer. They become the backlog for phase two. Without that documentation, they get forgotten and resurface as complaints six months later as if they were new.
Step 5: Run the Test, Don’t Wing It
UAT works best as a scheduled exercise, not as an open-ended “play with it for a few days” period. The scheduled version: testers know they have specific test cases, a defined window (typically three to five working days), a daily check-in with the project manager, and a clear deadline to submit their findings.
The open-ended version produces predictable failures: testers do not start until day five, do not finish, do not document properly, and the project manager has no view on progress. The scheduled version produces a tight, decisive UAT cycle.
The daily check-in is short — fifteen minutes. Each tester says what they tested, what passed, what failed, and what they are testing next. The project manager flags emerging patterns to the development team in real time, so blockers get fixed during UAT rather than at the end.
Step 6: Decide Sign-Off Honestly
At the end of UAT, the project owner — usually the operations lead or product owner — makes the sign-off call. The decision is binary: ship or not ship. The criteria, decided in advance, are: all blockers resolved, deferred items documented, test pass rate above a target threshold (typically 95% — perfection is not realistic and chasing it delays releases for diminishing returns).
If the test pass rate is below threshold or blockers remain, the release does not go ahead. This is the moment where commercial pressure tries to override the criteria — “we promised the team it would be live by Friday”. Resist it. A delayed release with the fixes in place is much better than an on-time release that breaks production and consumes the next two weeks in firefighting.
If sign-off is given, document it. A short note: the date, the testers, the test pass rate, the list of deferred items, and the sign-off itself. This protects everyone — the development team is no longer responsible for the deferred items being fixed without a separate scope; the business has a record of what was tested and accepted.
Common Mistakes
- Everyone tests. Opens the door to feedback that is not really UAT and turns the cycle into a wishlist gathering exercise. Limit to the people who actually use the system day-to-day.
- Test cases written too vaguely. Produces feedback like “the form is confusing” instead of “the form rejected a valid email address”. The test case discipline is what makes UAT useful.
- No smoke test. Wastes business testers’ time on issues that should never have reached them.
- No triage between blocker and defer. Every issue becomes a release-blocker by default, and the release never ships. Or no issue is a blocker, and the release ships broken.
- UAT as an open-ended period. People do not test if there is no deadline. Schedule it tightly with daily check-ins.
- Sign-off as a feeling. “It seems fine to me” is not sign-off. Document the test results, the open items, and the deferred backlog, in writing.
- Testing on a half-populated environment. A staging server with three test records does not exercise the system. Populate the test environment with realistic data before UAT begins.
What Good Looks Like
A well-run UAT cycle has three to six identified testers, twenty to a hundred test cases tied to the scope, a pre-UAT smoke test, a defined three-to-five-day testing window with daily check-ins, and a triage process that distinguishes blockers from deferred items. At the end, the sign-off decision is made against pre-agreed criteria, documented, and the deferred items become the explicit backlog for the next phase. The release ships with confidence on both sides. Six months later, when somebody asks why the system does or does not do something, the UAT documentation answers the question.
Next Steps
If the release is the final step before launch, How to Launch a Software Product Safely covers the rollout. If the system is replacing a manual process and the team needs to adopt it, How to Roll Out a New Internal System is the next read. For the deferred items that become phase two, How to Run a Software Review Quarterly covers the ongoing prioritisation.