Knowledge Base / Cheat-sheets
Client Feedback & UAT
Entry criteria and environment setup, running sessions without leading the user, triaging feedback into defect or scope change, sign-off against agreed exit criteria, and a dedicated tooling roundup - five sections you can filter and toggle as you verify them. Progress is saved on this device.
What this checklist covers
Preparing for UAT
Most UAT cycles fail before they start. They open on a build that is not ready, in an environment nobody can trust, with participants who were told about it that morning - and the resulting noise gets blamed on the users.
- System and integration testing are complete before UAT opens - UAT is acceptance confirmation, not a cheaper second round of functional testing.
- Entry criteria are written and agreed with the client in advance, so refusing to start on an unready build is a shared decision rather than a QA veto.
- Scope is stated as the business processes being accepted, not the screens being visited - users accept outcomes, not pages.
- The UAT environment is isolated from the team's own testing, so a colleague's data reset cannot invalidate a client's session mid-flow.
- Participants are actual users of the process, not their managers - the manager's mental model of the workflow is frequently out of date.
- One named person on the client side owns sign-off, because a cycle with a committee and no decider does not end.
Running the UAT Cycle
The balance to hold during execution: enough structure that the agreed scope is genuinely covered, enough freedom that users can do the odd real-world thing nobody scripted.
- Scenarios are written in the client's own business language, with their terminology and their data, not in the team's internal naming.
- Each scenario states the business outcome that constitutes success, so pass or fail does not come down to the participant's mood.
- The facilitator observes rather than guides - the moment you say 'click the blue button', you have destroyed the usability finding you were about to get.
- Hesitations, re-reads and wrong turns are recorded even when the participant eventually succeeds, since those are usability defects with a workaround.
- Reporting is made as low-friction as the team can manage - every extra required field converts some findings into unreported grumbles.
- Environment, role, timestamp and data used are captured automatically where possible, because users will not supply them reliably and QA cannot reproduce without them.
Handling the Feedback
The genuinely hard part, and the one that turns technical work into a commercial conversation. Most UAT friction is not about whether something is broken - it is about whether it was ever in scope.
- Severity (impact if it ships) and priority (when we fix it) are tracked separately, because conflating them is what produces the argument where everything is critical.
- Severity is assessed on business impact - blocked revenue, patient safety, regulatory exposure - not on how technically interesting the bug is.
- The distinction is drawn against the agreed requirement, not against what feels reasonable - 'the spec says X, the build does X, you now want Y' is a change, however sensible Y is.
- A requirement that was genuinely ambiguous is treated as a shared failure and split, rather than pushed onto whoever has less leverage.
- 'Won't fix' is delivered with the reasoning and the trade-off, because an unexplained rejection reads as dismissal and costs trust well beyond that one ticket.
- Deferrals name the release or the condition they are deferred to; 'later' is what stakeholders correctly hear as 'never'.
Sign-off & Closure
Sign-off is an informed acceptance of remaining risk, not a declaration that nothing is wrong. Treating it as the latter is how teams end up with a signature that does not survive the first production incident.
- Exit criteria were agreed at the start of the cycle, so the bar cannot be moved by whoever is under the most pressure at the end.
- Criteria are specific and checkable - scenario pass rate, zero open criticals, named must-fix list - rather than 'the client is happy'.
- Open defects going live are listed with their workarounds and shared with support before launch, not discovered by support during the first incident.
- Anything not covered during the cycle is stated as untested rather than left to be assumed passed - silence in a report is routinely read as a pass.
- Defects escaping to production are traced back to why UAT missed them, and the gap - not just the bug - gets fixed.
- Valid UAT findings are converted into regression tests, so acceptance work compounds instead of being repeated by hand each release.
UAT & Feedback Tooling
Tooling mostly buys you lower reporting friction and a shorter path from a user's complaint to a reproducible ticket. It cannot supply the agreed scope or the named decision-maker.
- Xray and Zephyr live inside Jira, which suits teams whose clients already work there and removes a second login from the participant's path.
- TestRail and qTest are standalone and better where UAT evidence has to be exported for audit or held apart from engineering's tracker.
- Usersnap, Marker.io and BugHerd let a user annotate the screen in place and attach console and environment data automatically - the single biggest reduction in reporting friction available.
- In-page capture writes straight into Jira or the tracker of record, so nobody re-keys tickets by hand.
- FullStory and Hotjar replay real sessions, which settles 'I clicked it and nothing happened' reports without a reproduction argument.
- UserTesting and Maze suit moderated and unmoderated usability rounds where the question is comprehension rather than correctness.
- A live dashboard of scenario status removes most status-chasing traffic and keeps everyone arguing about the same numbers.
- Confluence or an equivalent holds the scope, entry and exit criteria in one linkable place, so 'what did we agree' has an answer.