UAT sign-off checklist for software services projects
User acceptance testing goes wrong in the same few ways: nobody agreed what 'done' means, the client tests the wrong build, or acceptance is never written down. This checklist covers each step.
Before UAT starts
Agree these with the client in writing, ideally in the statement of work or the kickoff notes:
- Scope: the list of stories or features in this UAT round, by name.
- Acceptance criteria: for each story, what the client will check. Two to five plain sentences each.
- Who tests and who signs: named people on the client side, and who has the final say.
- Environment and data: which URL, which test accounts, and whether real data is allowed.
- Time box: how many working days UAT runs, and what happens if there is no response.
- Severity rules: what blocks acceptance (a defect in an agreed flow) and what doesn't (a new idea or a cosmetic issue).
Before you hand over the build
- Your own QA cycle is finished, and every test case for the scope has a result.
- Blocked and failed tests are listed as known issues, with a plan for each.
- API checks on the integrations in scope have passed on the UAT environment.
- The build or version number is recorded, so feedback can be traced to it.
- Test accounts work, and the client's testers can log in.
The handover message
- What is in this round, described as things a user can do.
- How it was tested: test counts with pass, fail and blocked.
- Known issues.
- Where to report problems, and the format you want (steps, expected, actual, screenshot).
- The sign-off date and the one action you need.
If you need a template, use this release message.
During UAT
- Log every piece of client feedback in one place, linked to the story it's about.
- Sort each item: defect in scope, change request, or question. Agree the label with the client.
- Fix defects in scope, retest them, and tell the client which build has the fixes.
- Move change requests to the backlog and estimate them separately. Don't let them block sign-off.
Recording acceptance
- Get acceptance from the named person, in writing: an email, a signed form, or a recorded sign-off.
- Record what was accepted: the release, the build and the date.
- Keep the test results and the sign-off together, with the release. Months later, this is your answer to "was this tested?".
- If the contract needs a signature, get one. A reply or a click on a link is good evidence, but it isn't a digital signature.
Common problems and fixes
| Problem | Fix |
|---|---|
| UAT never ends | Agree the time box and the no-response rule before you start |
| New requests keep arriving as "bugs" | Agree the severity rules up front, and move requests to the backlog |
| The client tested an old build | Put the build number in the handover and in every fix note |
| Nobody remembers what was accepted | Keep the sign-off with the release record, not in an inbox |
How NaatOps helps
NaatOps keeps the stories, test cases, test runs and API checks for a release together. A release report link lets the client see what was tested and accept the release or ask for changes, and the decision is kept with the release. It doesn't replace a signature where your contract needs one.
Stories, tests and API checks in one place
Free for up to 10 users. Team and Delivery start with a free trial, no card needed.