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.

Review the diff and impacted modules. Touching auth, billing, or shared API contracts is High risk and triggers full regression. Isolated UI copy change is Low. Pick the level honestly — High pulls in the full regression suite step later in this checklist.

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.

Build seed fixtures for happy-path users, edge-case accounts (expired trial, suspended, multi-tenant admin), and anonymized production-shaped data. Never copy raw production PII into staging — GDPR and HIPAA both prohibit it; use a masking script.

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.

Confirm in LaunchDarkly or Statsig that the flag default in staging matches the planned production rollout state (off, beta-only, or 100%). Flag misconfiguration is a top cause of "the feature works in staging but not for the customer" tickets.

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.

Time-box a 60–90 minute session-based exploratory test. Charter it ("explore the multi-tenant admin permission surface"), keep notes, file anything surprising. Scripted tests find what you thought to write; exploratory finds what you didn't.

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.

QA lead records the decision against the exact sha tested. "Approved with known issues" requires the issues listed and PM acknowledgment. "Blocked" sends the release back to engineering and pauses the deploy window. This record is SOC 2 change-management evidence — keep it.