Quality Assurance Checklist

Walk the Jira / Linear board for the release scope. Each story should have explicit Given/When/Then or bullet-form acceptance criteria — vague stories like "improve the dashboard" go back to the PM before QA picks them up.

Common offenders: "fast" without a latency budget, "works on mobile" without device list, "secure" without threat model. Push back to the PM/tech lead before test design — easier to fix wording than to argue about pass/fail later.

Every story ID maps to at least one test case ID. Stories with no coverage and tests with no story are both red flags. Spreadsheet or TestRail / Xray export is fine — what matters is that the gap shows up before the sprint ends.

One-page plan: in-scope features, out-of-scope, target browsers/devices, environments, entry/exit criteria, and the smoke vs. regression vs. exploratory split. Link from the release ticket so reviewers and the release captain can find it.

High = touches auth, billing, schema migrations, or data-loss-class paths. Medium = customer-visible feature with rollback. Low = copy/UI tweak behind a flag. The classification drives whether a full regression pass and load test are required.

Cover happy path, edge cases, negative cases, and at least one accessibility check (keyboard nav, screen reader label) per user-facing change. Reuse existing suites where possible — a 2,000-case regression with 40% duplicates is worse than a curated 600-case suite.

Confirm staging is on the release-candidate build, seed/anonymized data is loaded, and feature flags match the planned production state. Stale staging data is the most common reason a test "works in QA" and breaks in prod.

Trigger the Playwright / Cypress + unit + integration suites against the RC build. Quarantine flaky tests rather than reruns-until-green; a "just rerun it" habit hides real regressions.

Walk each new story's acceptance criteria on staging. Capture screenshots/Loom for anything that looks off — easier than a defect ticket reading "the layout is weird."

Latest Chrome, Safari, Firefox, Edge plus iOS Safari and Chrome Android per the support matrix. BrowserStack / Sauce Labs covers the long tail. Don't skip Safari — its CSS quirks bite at the worst time.

k6 or Locust against staging at 1x and 2x peak production traffic. Watch p95/p99 latency and error rate — a feature that's correct but blows the latency SLO is still a release-blocker.

Time-boxed 60–90 min sessions per area, charter-driven ("explore the new export flow with focus on permissions"). Defects found here are usually the ones scripted tests miss.

Each ticket: env, build SHA, steps, expected vs. actual, screenshot or HAR, severity (SEV1 data loss / SEV2 broken feature / SEV3 cosmetic). "Doesn't work" tickets bounce back and waste a day.

QA lead, tech lead, and PM agree on fix-now vs. ship-and-fix vs. won't-fix per defect. Document the call in the ticket — "deferred to next sprint, accepted by PM" beats a silent close.

Notify the release captain in #engineering, push the release date in the calendar, and set expectations with support. A held release with a clear ETA is far cheaper than a rolled-back release.

Re-test on the build that contains the fix (not the dev's local). Re-run the targeted regression around the changed code path — bug fixes are a top source of new bugs.

Cases planned vs. executed vs. pass/fail/blocked, automated coverage %, defects opened by severity, residual risks. Link from the release ticket so the release captain can read it in one minute.

If flake rate is climbing past ~2% or coverage on the new code is under target, file follow-up tickets now — easier than catching it three sprints later when the suite is unusable.

QA lead records the go/no-go decision with named residual risks. This is the artifact SOC 2 change-management auditors ask for, so keep it linked to the release ticket and the build SHA.