Release Readiness Checklist.

Each ticket/story in the release scope must have acceptance criteria that QA was involved in reviewing. Criteria written only by engineering or product — without QA input — commonly miss edge cases that produce late-breaking bugs.

Check the git log for the release branch between code-freeze and the release candidate build. Any post-freeze commit that was not explicitly approved via the exception process should block the release until re-tested.

Run 'npm outdated' or equivalent. For every dependency bumped in this release, confirm the changelog was reviewed and the affected flows were tested. Dependency upgrades cause a disproportionate share of production regressions.

List all feature flags toggled in this release. Verify the expected state (on/off) in staging and production. Confirm the flag can be toggled remotely without a re-deploy. Incorrect flag state is one of the most common 'release worked in staging, broken in production' causes.

Open the test management tool and confirm every test case assigned to this release has a result (pass, fail, or blocked — not 'not run'). 'Not run' test cases are unknown risk, not acceptable risk.

Confirm the CI pipeline ran the complete regression suite — not just the smoke suite — against the exact build artifact that will be deployed. Note the build hash or version number. A regression suite run on a previous build does not count.

Identify the top 5–10 user journeys by business impact (login, checkout, core feature activation). Each must have an automated E2E test that ran successfully in the release environment, not just in local or staging.

Pull the coverage report from the CI run for the release branch. New files/modules must meet the project's minimum threshold (e.g., 80% line coverage). Drops in coverage for existing code should be reviewed and justified.

Structured scripted tests catch known scenarios; exploratory testing catches the unexpected ones. For each significant new feature, confirm a tester ran at least a 30-minute exploratory session and logged their findings.

Pull the open-defect report filtered to: project = this release, severity = Critical/High, status ≠ Closed. The count must be zero. Any open critical/high defect must either be fixed and retested, or have an explicit documented waiver with product and engineering sign-off.

No Medium defect should be in an untriaged state at release time. For each: it is fixed (with regression test), deferred to a named next sprint, or documented as a known issue in the release notes. 'We'll look at it after release' is not an acceptable triage decision.

Compare the defect count and failure patterns against the previous release baseline. Any new test failures that were not failing in the prior release are potential regressions. Investigate and resolve or document before shipping.

Any defect consciously deferred to a later release must appear in the release notes with: a description of the impact, the conditions under which it occurs, and a workaround if one exists. Undisclosed known issues erode support team trust.

Open the latest CI run for the release branch. Every test must have a result: passed, failed (with a tracked defect), or intentionally skipped (with a skip reason and ticket). Disabled or commented-out tests represent hidden risk.

A flaky test that randomly fails signals instability in either the test or the application. Before releasing, review the flakiness report and ensure no test has both passed and failed in the last 5 runs without a code change between runs.

For each story in this release, verify the PR that merged the feature code also includes new or updated test files. Features without automated test coverage accumulate test debt that compounds with every release.

Run Lighthouse against the release candidate in a controlled environment. LCP < 2.5s, CLS < 0.1, and INP < 200ms for the pages most traffic hits (homepage, login, core feature). A regression > 20% vs the previous release baseline must be investigated.

Run a load test against the release candidate targeting peak expected traffic. Check p50, p95, and p99 response times for: login, main data-fetch endpoints, and the write endpoints most commonly used. Any p95 > SLA is a blocking issue.

For every new or modified query in the release, run EXPLAIN (or EXPLAIN ANALYZE in PostgreSQL) against a dataset representative of production size. Queries with sequential scans on large tables must be addressed before release.

For single-page apps, open Chrome DevTools Memory profiler, use the app intensively for 10 minutes, and take heap snapshots. Memory should stabilise, not grow linearly. For long-running backend processes, monitor memory over a 1-hour load test run.

Run 'npm audit --production' and filter for Critical and High severity findings. These must be zero or have documented mitigations. Dev-only dependency vulnerabilities can be waived, but production deps require action.

Run the configured SAST tool (Snyk, SonarQube, Veracode, etc.) on the release branch. Compare findings to the last release. New critical findings block release. Pre-existing findings must have tracked suppression tickets.

Run the automated accessibility suite against the release candidate. Critical violations (missing alt text, broken ARIA roles, missing form labels) must be zero. This is a minimum bar — it does not replace manual keyboard and screen reader testing.

Release notes must be ready before the release goes out — not written post-deployment. They must cover: new features (with brief descriptions), breaking changes (with migration steps), deprecated APIs/features, and known issues with workarounds.

Compare the current API spec (OpenAPI/Swagger) against the previous version. New endpoints must be documented with request/response schemas and examples. Removed or changed endpoints must be marked deprecated or updated. Stale API docs cause integration failures for consumers.

The deployment runbook must document every manual step: database migrations to run, feature flags to flip, third-party configs to update, and health checks to verify. It must be reviewed by someone who was not involved in writing it, to catch assumed knowledge.

Run the migration scripts against a staging database that mirrors production in terms of row count and data distribution. Record the execution time. If the migration takes > 5 minutes on production data, it must be broken into smaller batches or run with a maintenance window.

For every new feature in this release, confirm the relevant metrics are being emitted and appear in the monitoring dashboard. If a new endpoint was added, its error rate and p95 latency must be visible. Release without updated dashboards means flying blind.

For each critical new endpoint, confirm an alert rule exists for: error rate > X%, and p95 latency > Y ms. The alert must route to the on-call rotation, not just a Slack channel that may be muted. Test the alert fires by temporarily lowering the threshold.

The rollback must be documented with exact commands (git revert + deploy, blue/green switch, or canary rollback). It must have been executed in staging at least once in the last 3 months. 'We can roll back' is not enough — 'we have rolled back and it took 8 minutes' is.

Define the criteria for promoting the canary to full traffic: e.g., 'error rate < 0.5% for 30 minutes at 10% traffic'. These criteria must be written down before deployment — not decided ad-hoc during the deployment window.

Sign-off must be recorded in a traceable location (Jira ticket, release issue, Slack thread with a date stamp). Verbal agreement in a standup does not count. Sign-off documents who approved what — critical for post-incident retrospectives.