Acceptance Testing Checklist

Walk each user story's acceptance criteria with the PO before testing starts. Ambiguous criteria ("works as expected", "performs well") must be tightened into observable, testable outcomes — otherwise functional sign-off becomes a debate during the release window.

Refresh the UAT database from a sanitized production snapshot so test data resembles real customer shapes. Confirm feature flags, secrets, and third-party sandbox endpoints (Stripe test mode, sandbox SSO IdP) match what production will see.

Map test cases one-to-one against acceptance criteria. Flag cases that are automated vs. manual; the manual list is what the QA team executes in this run, the automated list lives in the regression suite covered later.

Execute each story's manual cases in the order an end-user would. Record defects directly to Jira/Linear with the story link, environment, build SHA, and reproduction steps — not just a screenshot.

Run the e2e suite against the UAT build. Triage any failures into real regressions vs. flakes; flakes get tracked separately so the green/red signal stays meaningful.

Run contract tests (Schemathesis, Dredd, or Pact) so undocumented field changes don't slip through. Breaking changes to public endpoints require a deprecation cycle, not a silent ship.

Drive expected peak RPS for at least 30 minutes against the UAT cluster, sized to match production. Capture p50/p95/p99 latency, error rate, and saturation on the golden signals dashboard.

Ramp load past expected peak until the system degrades. Note where it breaks first — DB connection pool, downstream API rate limit, CPU saturation on a specific service — and confirm autoscaling reacts before users see errors.

Compare measured p95/p99 against the documented SLO. A regression vs. last release's baseline counts as a breach even if the absolute numbers are still under SLO — that's how slow drift gets caught.

Trigger Semgrep / CodeQL for SAST and Snyk / Dependabot for SCA against the release SHA. Triage criticals and highs; transitive CVEs without a fix path get an explicit risk acceptance, not a silent skip.

Pair with AppSec on any auth, authz, or data-handling changes in this release. New endpoints get a quick threat-model review against the OWASP Top 10 — IDOR and broken access control are the most common findings on feature releases.

Cross-check the latest pentest report against this release's scope. SOC 2 auditors will look for evidence that critical/high findings were closed before promotion; a screenshot of the ticket-closed state attached here is the audit trail.

Recruit 5–8 representative users for the new flows and observe via Loom or a moderated UserTesting session. Watch for hesitation, dead-end states, and confused terminology — these rarely surface in internal dogfooding.

Run axe or Lighthouse on every new screen plus keyboard-only navigation through the changed flows. Color contrast, missing labels, and focus-trap on modals are the recurring offenders. Public-sector and EU customers expect AA conformance.

Kick off the nightly regression pipeline against the release candidate SHA. Attach the CI run URL here; a green run alone isn't sign-off — flakes have to be investigated, not retried until green.

For each failure, decide: real regression (fix and re-run), known flake (quarantine with a tracking ticket), or environmental (UAT-only, document and override). "Just rerun it" without classification is how flaky suites lose their signal.