Regression Testing Checklist

Provision the staging cluster from the same Terraform / Helm config used for production. Drift between staging and prod is the most common reason a green regression run still ships a regression — pin instance sizes, AZ layout, and k8s versions to match.

Confirm versions of upstream services, queues, and third-party stubs match prod. Pin image SHAs, not latest tags — moving tags hide subtle regressions and break reproducibility for incident replay.

Use a recent prod snapshot with PII scrubbed per your data-handling policy (HIPAA / GDPR / customer DPAs). Stale fixtures are the leading source of false-positive failures from schema drift.

Run a restore drill into a scratch database. A backup that has never been restored is theater; SOC 2 auditors look for evidence of periodic restore tests, and the regression cycle is a good place to capture it.

Pull the list of merged PRs and epics since the last release. Confirm the test plan has coverage for each user-visible change, infrastructure migration, and feature flag flip planned for this deploy.

Walk the suite with the feature owner. Cases that test deprecated flows should be archived, not left to fail mysteriously next cycle and waste an SDET hour.

Trigger the full pipeline (Jest / pytest / Playwright / Cypress) against the candidate build. Don't run locally — CI parity matters because flakes correlate with environment differences the local box hides.

Walk the failure list and fix selectors, API contracts, and assertion drift. Distinguish real regressions from script staleness — only the former blocks release; the latter blocks the SDET.

Use the standard load profile (e.g., 500 RPS for 10 minutes across the top 5 endpoints). Match staging instance sizes to prod or note the discrepancy explicitly in the report.

Pull the dashboard from the previous regression cycle (Datadog / Grafana). A 10%+ degradation at p99 is the threshold most teams treat as a release blocker; tune the threshold to your SLO error budget.

Filter the tracker for defects marked Fixed since the last regression. Each one needs a retest against this candidate, not a "trust the developer" sign-off.

Reproduce the original repro steps and confirm the bug no longer occurs. Retest in the same browser, OS, and tenant configuration from the original report — fixes that pass on Chrome can still fail on Safari.

Walk the top user journeys (login, checkout, primary CRUD flows, billing). Coverage on revenue-impacting paths is non-negotiable; long-tail features can ride lower coverage with documented risk.

Cover each feature behind a flag that's flipping on this release. Include a kill-switch revert test so the rollback path is exercised before you need it at 2am.

Run the suite against the release candidate in staging. Capture the CI run ID — downstream defect tickets and the report will reference it for traceability.

Attach the failing run's logs, screenshots, and HAR files to each defect. "It failed once" is not a defect report; reproducible failures with artifacts are.

Each defect gets steps to reproduce, expected vs. actual, environment, and severity. Severity follows the team's rubric — SEV1 blocks release, SEV2 blocks the next release, SEV3 is backlog.

Look for clusters — same service, same user path, same data shape. Patterns point at root causes (a flaky upstream, a leaked migration, a noisy dependency) that single-defect investigations miss.

Summarize pass/fail counts, performance deltas, defects by severity, accepted risks, and a recommended go/no-go. The report goes to the release captain, eng leadership, and product owner before the sign-off meeting.