Test Plan Checklist
Steps a QA lead runs to author a release test plan — scope, environments, test data, traceability, and sign-off — before a feature ships to staging. Use once per major release or feature epic.
Strategy and Objectives
-
Define in-scope features and out-of-scope areas
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.
-
Set entry and exit criteria
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%+).
-
Choose the test approach for this release
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.
Collects list Collects paragraph
Resources and Roles
-
Assign test owners per feature area
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.
-
Confirm tooling access for the test team
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.
-
Identify training gaps for new tooling
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.
Schedule and Test Cycles
-
Build the test schedule against the release date
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.
-
Define the test levels for this release
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.
-
Plan the test case authoring and review cycle
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.
Test Environment
-
Provision the staging environment
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.
-
Verify staging parity with production
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.
Collects list Collects paragraph -
Set up environment availability tracking
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.
-
Document the parity remediation plan
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.
Risk Assessment
-
Catalog the release risks
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.
-
Write mitigations for high-likelihood risks
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.
-
Document the rollback plan
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.
Collects list
Communication and Reporting
-
Set up the daily test status standup
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.
-
Configure the defect triage workflow
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.
-
Prepare the test summary report template
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.
Requirements Traceability
-
Confirm acceptance criteria are testable
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.
-
Build the requirements-to-test-case matrix
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.
Collects file -
Flag uncovered requirements for review
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.
Test Data Management
-
Inventory the test data needs
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.
-
Generate or refresh fixtures from production snapshots
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.
-
Apply PII scrubbing for non-prod data
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.
Collects list -
Remediate the PII finding before execution
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.
Quality Gates and Sign-Off
-
Lock the quality metrics for this release
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.
-
Run peer review on the test plan
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.
-
Sign off the test plan
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.
Collects list Collects paragraph Collects signature
Use this template
Copy it to your account, customize the steps, and run it with your team in minutes.
Browse hundreds of free templates across every team and industry.
Back to template libraryRun Test Plan Checklist with your team
Customize the steps, assign roles, set a schedule, and keep a complete record for every run.