User Acceptance Testing (UAT) Checklist

List the user stories, epics, or Jira tickets in scope for this release. Pull acceptance criteria directly from the ticket — if criteria are missing or vague, send back to the PM before scheduling testers. Out-of-scope items (regression areas, deferred features) get an explicit exclusion list to prevent scope creep mid-cycle.

Pick 3-6 end users who actually use the affected workflows daily — not their managers, not engineers proxying for them. Confirm calendar availability for the full execution window and that they have prod-equivalent permissions in the UAT environment.

Verify the UAT environment is on the release-candidate build, has anonymized prod-like data seeded, and integrates with sandbox versions of third-party services (Stripe test mode, sandbox SSO, etc). Mismatched environment is the most common reason UAT defects don't reproduce in prod and vice versa.

Share a Confluence or Notion page with the test window, daily check-in time, defect-logging process (Jira project + label), severity rubric, and the named decision-maker for go/no-go. Distribute to participants, eng leads, and the release captain.

One test case per acceptance criterion at minimum, plus negative paths and edge cases (empty state, permission boundary, concurrent user). Use the team's standard format — TestRail, Xray, Zephyr, or a structured Notion template — so results roll up cleanly.

Walk the PM through coverage gaps; walk the tech lead through whether any cases are testing implementation details that should be unit tests instead. Adjust before kick-off — rewriting cases mid-execution wastes tester time.

Create the user accounts, tenant orgs, sample records, and edge-case data (long strings, unicode, large file uploads) the test cases reference. Document credentials in 1Password or the team's secret manager — never paste into Slack or the test plan doc.

Confirm the SHA or release tag (e.g., v2024.45.0-rc.1) deployed to UAT matches what's planned for production. Run the smoke test suite to catch deploy-time breakage before testers waste time on it.

30-minute session: walk testers through the environment URL, login flow, where to find test cases, how to log defects (Jira project, required fields, severity rubric), and the daily standup time. Record it for testers who join late.

Testers mark each case Pass / Fail / Blocked with screenshots or Loom recordings on failures. QA lead monitors the run daily and unblocks testers who are stuck on environment issues vs. real defects.

Each defect needs: clear repro steps, expected vs. actual, screenshot/video, environment, build SHA, and severity (SEV1 blocks release, SEV2 needs fix before GA, SEV3 can ship and follow up). Tag with the UAT cycle label so they roll up.

15-minute standup: PM, QA lead, tech lead. Review new defects, confirm severity, assign owners, decide whether each is must-fix-before-GA or deferrable. Avoid defect sprawl by closing duplicates and rejecting out-of-scope reports same-day.

For each in-scope ticket: did the test cases for its acceptance criteria pass? A ticket with one passing case but unaddressed criteria is not done. Flag any acceptance criterion with no covering test as a process miss for the next cycle.

Categorize each open defect: must-fix-before-GA, ship-with-known-issue (with workaround documented), or defer to next release. Any SEV1 unresolved is automatic no-go; SEV2 requires explicit business owner waiver.

Engineering ships fixes for blocking defects on a hotfix branch off the release candidate, redeploys to UAT, and the original tester re-runs the failing case. Do not skip re-test — fixes regularly introduce new failures elsewhere.

Named business owner reviews the UAT summary (cases passed, known issues with workarounds, deferred items) and signs off in writing. Slack approval doesn't count for SOC 2 change-management evidence — capture the decision, decision-maker, and date.

Attach test cases, execution report, defect list, and sign-off to the release ticket or change-management record. SOC 2 ITGC auditors will ask for this trail by release; having it filed at closeout is far cheaper than reconstructing it at audit time.

Post a short summary: scope shipped, known issues with linked Jira tickets and workarounds, and any items deferred to the next release. The release captain uses this to update release notes and the customer-facing changelog.

30-minute retro with PM, QA lead, tech lead, and one or two testers. What slowed us down (environment issues, missing test data, vague acceptance criteria)? Capture 2-3 action items with owners; review them at the start of the next UAT cycle.