User Acceptance Testing Checklist: Plan, Run, Sign Off
Short answer
A user acceptance testing checklist confirms that entry criteria are met, real users test agreed scenarios with realistic data, every defect gets a severity and deadline, and a sign-off record states what was accepted, with which reservations. Prepare acceptance criteria before development starts, because UAT can only check what was agreed in writing.
Signing off a software project takes ten seconds. Those seconds change the commercial position more than anything else in the project. Payment typically falls due, warranty periods start running, and defects you knew about but didn’t record can become very hard to claim later.
Yet acceptance is often handled in passing, with an email that says “looks good to us”. That’s risky for both sides.
What UAT is for, and what it isn’t
User acceptance testing answers one question: does the delivered system support the business process it was built for? It isn’t a second round of QA. The supplier should already have tested that buttons work and data saves correctly. UAT puts real users in front of the system with realistic tasks and data, and it ends in a decision with contractual consequences.
How much those consequences weigh depends on the contract and jurisdiction. Under German law, for example, § 640 BGB says a client can’t refuse acceptance for insignificant defects, treats the work as accepted if the client lets a reasonable deadline pass without naming at least one defect, and limits certain remedies for defects the client knew about but didn’t reserve at acceptance. Some English-language contracts contain similar “deemed acceptance” clauses. Read yours before testing starts.
Entry criteria: are you ready to start?
Starting UAT too early wastes users’ time and burns goodwill. Check these first:
- Acceptance criteria are written down and agreed, ideally in the spec or user stories
- Supplier has finished its own QA and shared the results
- No open defects of the highest severity from QA
- Test environment mirrors production: same configuration, integrations connected
- Realistic test data loaded, including edge cases and anonymised real records
- Testers named, briefed and given accounts with the right roles
- Test cases prepared and assigned
- Defect reporting channel and triage meeting agreed
- Contractual UAT period and deadline confirmed in writing
The first item decides everything else. If criteria only get discussed during UAT, acceptance turns into a negotiation. Requirements written as user stories with acceptance criteria or in a structured requirements document already contain most of your test cases.
A test case template that users can follow
Business users aren’t professional testers. Give them cases they can run without help:
| ID | Scenario | Steps | Expected result | Pass/Fail | Notes |
|---|---|---|---|---|---|
| UAT-07 | Refund for a returned order | Open order 10452, choose Refund, select two of three items, confirm | Refund of the two items’ value is shown; customer email sent within 5 minutes | ||
| UAT-08 | Refund above approval limit | Open order 10488 (total $1,250), choose full refund | System asks for supervisor approval before issuing | ||
| UAT-09 | Report export | Run the monthly returns report for October, export to XLSX | File opens in Excel, totals match on-screen figures |
Concrete order numbers and amounts matter. “Test a refund” gets you ten testers doing the same easy case. Specific scenarios, including awkward ones such as approval limits, find the problems.
Defect severity: not every bug is equal
Three severity levels turn a long bug list into something you can decide on:
| Severity | Meaning | Example | Consequence |
|---|---|---|---|
| 1, blocking | Core function unusable, no workaround | Invoices aren’t generated | Refuse acceptance |
| 2, major | Function impaired, workaround exists | Export only as CSV, not XLSX | Accept with reservation and fix deadline |
| 3, minor | Cosmetic, no effect on the process | Typo in a message | Accept, fix in next update |
Refusing acceptance is normally justified only by blocking defects. Several major ones together can add up to the same thing, and the sign-off record should explain why.
Keep one rule firm: a new wish is not a defect. If something was never agreed, it’s a change, and it belongs in the change request process, not the defect list. This single distinction prevents more acceptance disputes than any template.
Exit criteria and the sign-off record
UAT ends when the agreed exit criteria are met. Typical ones: all planned test cases executed, no open severity-1 defects, every severity-2 defect has an agreed fix date, and documentation has been handed over.
The sign-off record should contain:
- Project, contract reference and release or version accepted
- Date, environment and participants, with who holds authority to accept
- Test cases run and their results, or a reference to the test log
- Every open defect with severity and fix deadline
- An explicit reservation of rights for each known defect
- Handed-over items: documentation, credentials, source code, licences
- Decision: accepted, accepted with reservations, or refused with reasons
- Signatures from both parties
For the reservation, plain wording works: “The client reserves all rights in respect of defects 1 to 4 listed above.” Not elegant. Unambiguous.
Four mistakes that keep recurring
The system has been in live use for weeks with no sign-off. Depending on the contract, that can count as acceptance by conduct, without any reservations recorded.
Testing uses three sample records. Problems that only appear with 50,000 customers, or with accented characters in names, stay hidden until launch.
The tester is the project manager alone. Without real users in the room, workflow gaps surface after go-live, when fixing them costs most.
Documentation gets forgotten. Without credentials, a runbook and source code, an accepted system is hard to maintain or hand to another supplier.
Staged acceptance for iterative projects
One big acceptance at the end of a year-long project concentrates risk. Staged acceptance per release or milestone is easier, if the contract allows it. Each round is manageable, defects surface earlier, and the supplier gets staged payments. How to slice a project into such stages is covered in agile vs waterfall. Agree whether a final overall acceptance follows, for example to test how all modules work together.
If you’re planning a build with an external partner, raise acceptance criteria and procedure at the quoting stage. With a studio such as OnlineBuilders, that’s part of the free initial technical consultation, and it saves time and nerves at the end.
Next step: check your current contract for three things. Are acceptance criteria defined, is there a deadline for the UAT period, and does it name who may accept? Fill in whichever is missing before the supplier reports the system ready.
Questions people ask
Who should perform user acceptance testing?
People who will actually use the system: two or three representatives of each main user group, plus the person with contractual authority to accept. Developers and QA staff support but shouldn't be the testers, because UAT checks fitness for business use, not just technical correctness.
How long should UAT take?
For a mid-sized business application, one to three weeks is common, including one round of fixes and retesting. Agree the duration in the contract, because some agreements treat silence after a set period as acceptance.
What is the difference between QA testing and UAT?
QA testing checks that the software works as specified, usually done by the supplier. UAT checks that it supports the real business process, done by the client's users, and ends in a formal acceptance decision.
Can you accept software with known defects?
Yes, and it's common for minor issues. List every known defect in the sign-off record with a fix deadline and an explicit reservation of rights. Under some legal systems, including German contract law, accepting a defect you knew about without reserving rights can cost you remedies.
