Test Plan Checklist

List the epics, stories, or Jira/Linear tickets the test plan covers and the modules explicitly excluded. Out-of-scope areas are where regressions hide — call them out so stakeholders agree before exit criteria are written.

Entry: code-complete on release branch, unit tests passing in CI, deploy to staging successful. Exit: zero open SEV1/SEV2 defects, p95 latency within SLO, planned test cases executed with documented pass rate (typically 95%+).

Pick the mix: risk-based exploratory, scripted regression, automated e2e in Playwright/Cypress, contract testing for API changes. A schema migration calls for a different approach than a UI refactor.

Map each in-scope module to a named QA engineer or SDET. CODEOWNERS plus a test-owners matrix prevents the "everyone tests, nobody owns" gap that surfaces at sign-off.

Verify access to TestRail/Xray, Playwright/Cypress runners, BrowserStack or Sauce Labs, Postman collections, staging credentials in 1Password, and Datadog/Sentry dashboards. Missing access on Day 1 of execution loses half a day.

If this release introduces new tools (Playwright migration from Cypress, contract testing with Pact, k6 load testing), schedule a 30-minute walkthrough before execution starts. Don't assume self-service learning during a release window.

Backwards-pace from the release date: code freeze, regression cycle, UAT window, go/no-go review. Leave a buffer day before deploy — every release plan that lands tests on the release-day morning produces a hotfix the next week.

Decide which levels apply: unit (dev-owned, already in CI), integration, system, e2e, performance, accessibility (WCAG 2.1 AA if customer-facing), security. Not every release needs every level — name the ones that do.

Authoring in TestRail or Xray, peer review by another QA, sign-off by the feature engineer who wrote the code. Reviewing test cases with the implementer catches misread acceptance criteria before execution starts.

Confirm Terraform/Pulumi has applied the staging stack, container images are deployed from the release branch, RDS has the migrated schema, and feature flags are in their planned starting state. Document the deployed sha so testers can correlate failures to commits.

Diff staging vs prod on instance sizes, environment variables, third-party integrations (sandbox vs live), and data volume. "Works in staging, breaks in prod" is almost always a parity gap — Stripe sandbox keys, smaller DB, missing CDN config.

Post a #staging Slack channel topic with current deployed sha and known issues. Add a status-page-style banner if shared with other teams. Reduces "is staging up?" interruptions during execution.

For each documented gap, decide: fix before execution, mitigate with manual workaround in test cases, or accept and add risk-acceptance note for the go/no-go review. Don't start execution with unresolved gaps and no plan.

Cover technical risks (irreversible migrations, third-party API changes, breaking schema changes), schedule risks (engineer PTO, dependency on another team), and customer risks (high-volume tenants on the affected code path). Score each on likelihood × impact.

Each high-impact risk gets a named owner and a mitigation: feature-flag the rollout, shadow-traffic the new code path, dark-launch the migration, or stage to 5% canary first. "We'll watch for it" is not a mitigation.

Confirm the previous container image is still in ECR, the DB migration is reversible (or backwards-compatible), and the feature flag kill-switch is wired. An untested rollback is no rollback — the only proof is a quarterly drill.

15-minute standup during execution: pass rate, new defects, blockers. Async update in #qa-release-{version} on non-execution days. PM and engineering manager attend the day before go/no-go.

Define severity in Jira/Linear: SEV1 blocks release, SEV2 ships with workaround, SEV3 deferrable. Triage twice daily during execution. Without explicit severity definitions, every defect becomes "high" and the go/no-go meeting is unwinnable.

Sections: scope tested, pass/fail counts, open defects by severity, exit criteria status, sign-off recommendation. The PM and engineering director read this at go/no-go — write the template before execution so it fills itself in.

Read each story's acceptance criteria as a tester. "User experience is improved" is not testable; "checkout completes in under 3 seconds at p95" is. Send untestable ACs back to the PM before authoring test cases.

One row per acceptance criterion, columns for the linked test case ID(s) and execution status. TestRail and Xray generate this from Jira links automatically; for spreadsheet-based tracking, the matrix is its own deliverable.

Any acceptance criterion with no linked test case is either out-of-scope (document it) or a coverage gap (author the case). Surface gaps in the test plan review, not at go/no-go.

List test users (free tier, paid tier, admin, legacy schema), seeded org fixtures, sample uploads, and any third-party sandbox accounts (Stripe test cards, Twilio sandbox numbers). Authoring test cases without this list produces "works on my fixture" failures.

Use a sanitized prod snapshot or a faker-generated fixture set. Document the generation script in the repo so the next release reproduces the data state. Stale fixtures from 6 months ago miss schema changes.

Email, name, address, payment data must be scrubbed or synthetic — GDPR Article 5 minimization and SOC 2 confidentiality controls apply to staging too. Auditors check that prod PII is not present in lower environments.

Run the scrubbing script against the staging DB, rotate any leaked credentials, and notify the security/compliance lead. Document the incident in the SOC 2 evidence folder if an auditor will ask about it. Do not start execution against unscrubbed data.

Pin the targets: test pass rate ≥ 95%, zero open SEV1, code coverage delta ≥ 0%, p95 latency within SLO on perf tests. Locking these before execution prevents the "let's lower the bar" conversation at go/no-go.

QA lead from a sibling team, the feature tech lead, and the PM read the plan and call out gaps. Track comments to resolution. A 30-minute review here is cheaper than discovering missing scope mid-execution.

QA lead, engineering manager, and PM confirm: scope agreed, environment ready, data ready, exit criteria locked, rollback plan documented. Attach the signed plan to the release ticket so it's part of the SOC 2 change-management evidence trail.