Igor Yussupov
Most go-live problems that UAT should have caught were not missed by testers. They were missed because the round was set up badly: the wrong data, an approver who was never named, defects reported in three places. This checklist has 20 things to confirm before you call a UAT round finished and release, grouped by the part of the round they belong to. Use it at the start of the round as well as the end; every item is cheaper to fix early.
Scope and people
- The scope is written down, including what is out. A list of the workflows and roles this release covers, and a list of what testers should ignore.
- One approver is named. One person with the authority to accept the release, and a named stand-in.
- Testers are confirmed and have time booked. Real hours in their calendars, not a hope that they will fit it in.
- A developer answers questions the same day. Someone is on call for the round and testers know who.
Environment and data
- The environment is separate and production-like. Same configuration as production, and no one deploying to it mid-test without telling testers.
- The test data is realistic, current and safe. Sensitive personal data is masked, and the data looks like what the business really handles.
- Every tester can log in before day one. Accounts, roles, VPN and passwords checked in advance, so the first morning is not spent on access.
- Third-party integrations are deliberate. Payments, email and other external services are in sandbox mode or switched off, so testing cannot charge a card or email a customer.
Test scenarios
- Scenarios follow real business processes. They are written as the work people do, not as a tour of the screens.
- Every scenario has an expected result a non-developer can judge. "The invoice total matches the order" beats "the API returns 200".
- Every user role is covered. Not only the administrator account that the developers use.
- Unhappy paths are included. Refused permissions, cancellations, wrong entries and empty states.
Defects
- There is one place to report a defect. Every tester can say where, without asking.
- Reporting does not need technical skill. Testers should be able to point at the problem and describe what they expected. If your process asks business users for console output, they will skip it.
- Severity levels are defined with examples. Agreed before the first report arrives, so rating is not a debate each time.
- Someone triages new defects every day. Each one gets an outcome: fix now, fix later, or not a defect, and the reporter is told.
Go-live readiness
- Exit criteria were agreed before testing began. And the results are measured against them, not against how the round feels.
- Every fix has been retested. Ideally by the person who reported the defect, on the build that will ship.
- The sign-off is recorded. Who approved, when, which build, and which known issues were accepted.
- The first days after go-live are covered. Someone watches, and users know how to report a problem on the live system.
How to use the list
Run through items 1 to 8 before the first tester logs in; they are about setup and cost nothing to fix then. Check 9 to 16 during the round, in the daily triage. Items 17 to 20 are the final gate. If you cannot tick one, write down why and let the approver decide whether to proceed. A known gap that someone accepted is a decision. An unknown one is a surprise.
For a plan that covers these points in one document, see the UAT guide. If you need a structure to start from, use the UAT test plan template.
Where SnagRelay fits
Items 13 and 14 are the ones people underestimate. SnagRelay is built for them: a tester clicks Report, points at what is wrong and writes what they expected. The element, console errors, failing requests and steps are attached, and the ticket goes to your tracker or the SnagRelay inbox, so developers do not have to go back with questions. The tester gets an email when it is marked resolved, which helps with item 18. It does not manage test cases or the sign-off (items 9 to 12, 17 and 19): keep those in your own tools. More on UAT with SnagRelay, and the Chrome extension if you cannot add a script to the staging site.
FAQ
What should be checked before go-live after UAT?
That the agreed exit criteria are met, every fixed defect has been retested, remaining known issues have been accepted by the approver, and the sign-off is recorded with the build it applies to.
How many testers does a UAT round need?
Enough to cover every user role and every main workflow. That is a question about coverage, not a fixed number. A role with nobody testing as them is a gap in the round, however many other testers you have.
Who is responsible for UAT sign-off?
The business. The named approver decides, with input from the testers and the project team. QA and developers inform the decision but do not make it.
What if we find a serious defect on the last day?
That is what the exit criteria are for. If you agreed beforehand that no open Critical defects may ship, the decision is already made. If you did not, the approver decides with the facts in front of them, and the decision is recorded.