QA Testing Checklist

Pull the Jira/Linear ticket and read the acceptance criteria line by line with the PM and the implementing engineer. Flag ambiguous wording ("the system should be fast") and pin down concrete expected behavior before any test design begins. Vague AC is the most common reason QA finds defects late.

For each user story, list boundary inputs, invalid inputs, concurrent-user scenarios, and failure modes (network drop, expired session, partial write). Edge cases the PM didn't write down are the ones customers will hit.

Lock the supported browser/OS/device matrix for this release — typically last two versions of Chrome, Safari, Firefox, Edge, plus iOS Safari and Android Chrome. Note any WCAG 2.1 AA accessibility requirements if the feature is in a public-sector or EU-Accessibility-Act path.

Document scope, in/out, entry and exit criteria, environments, and the responsible tester per area. Link the AC ticket and the design doc. The plan is the artifact auditors ask for during SOC 2 change-management evidence collection.

One test case per acceptance criterion plus edge cases identified earlier. Each case has preconditions, steps, expected result, and traceability back to the user story. Skip the temptation to write "verify it works" — that's not a test case.

Stable, high-value, repeated paths get automated; one-off exploratory checks stay manual. Avoid automating flaky areas (third-party iframes, animation-heavy flows) — they become noise in CI and trigger "just rerun it" culture.

Trigger the GitHub Actions or Buildkite pipeline that builds the RC tag (e.g., v2024.45.0-rc.1) and deploys it to staging. Confirm the deployed sha matches the release branch head; mismatched shas cause hours of "why doesn't this fix appear?" debugging.

Apply migrations against staging and watch for long locks or backfill blocks — the same operation will happen in prod next week. Load seed fixtures from the prior step.

Trigger the Playwright/Cypress suite against staging. Investigate every failure — do not retry-until-green. Flaky tests get tagged and filed, not silently ignored.

Walk through each test case in TestRail/Xray and mark pass/fail with the exact build sha. Attach screenshots or screen recordings on failure — "button broken" without artifacts is uninvestigable an hour later.

Use BrowserStack or Sauce Labs for the matrix locked in requirements review. iOS Safari and Android Chrome remain the most common source of "works on my machine" defects.

Triggered when regression risk was scored High in requirements review. Run the full automated regression pack and re-execute manual smoke for billing, auth, and shared APIs. Skipping this on a High-risk diff is how a one-line change ships an outage.

Each defect ticket includes build sha, environment, browser/OS, exact steps, expected vs. actual, and severity. Link console errors and Sentry events. Tickets without repro steps bounce back to QA — write them once, properly.

Walk the defect list with the engineering lead and PM. Classify each as release-blocker, fix-in-patch, or backlog. SEV1/SEV2 in customer-facing paths are blockers; cosmetic copy issues are not.

For each fixed defect, retest against the new RC sha and mark verified in TestRail. Common gotcha: the fix lands on main but the RC branch wasn't updated — confirm the sha actually contains the fix before retesting.