Release readiness: a QA checklist before every deploy

A release readiness checklist answers one question: should we ship this build? Not "is it perfect" because nothing is. Should we ship it, knowing what we know right now about what works, what doesn't, and what we haven't tested yet?

The answer is always a tradeoff. Ship too early and users hit bugs. Delay too long and the business loses time. The checklist doesn't make the decision for you. It gives you the information to make it well.

The World Quality Report 2025-26 found that nearly 90% of organizations are investing in quality engineering, yet release-related incidents remain common. The issue usually isn't that teams skip testing. It's that the testing results aren't organized in a way that supports a clear go/no-go decision. A checklist fixes that.

The release readiness checklist#

Here's the checklist I've used across multiple teams and products. Adapt it to your situation, but don't cut the core sections.

1. Regression suite status#

Run your full regression suite against the release candidate build. Not against yesterday's staging build. Not against a build that's "basically the same." Against the actual artifact you plan to deploy.

Record the results:

• Total test items executed
• Pass count and percentage
• Fail count with ticket numbers for each failure
• Blocked count with reasons
• Skipped count with justification

Your regression suite should cover the paths users hit most often: login, core workflows, payment (if applicable), and the features changed in this release. If you don't have a regression suite yet, our regression testing checklist can help you build one.

2. New feature testing#

Every feature added or changed in this release needs its own test pass. Regression covers existing functionality. This section covers what's new.

For each new feature or change:

• Were test cases written and reviewed?
• Were all test cases executed against the release candidate?
• What's the pass rate?
• Are there open bugs? If yes, what's their severity?

If a new feature has untested areas, be explicit about it. "We tested the happy path for the new export feature but didn't cover CSV files with more than 10,000 rows" is useful information for the go/no-go decision.

3. Known bugs inventory#

List every known bug in the release candidate. For each one, record:

• Bug ID and title
• Severity (critical / high / medium / low)
• Affected user flow
• Workaround available? (yes/no, with description)
• Product owner sign-off to ship with this bug? (yes/no)

This is the section that prevents the "wait, we shipped with THAT bug?" conversation after release. If a bug is in the inventory and the product owner signed off, the decision was conscious. If a bug wasn't in the inventory, your testing missed it, and that's a different conversation.

4. Environment verification#

The release candidate should be tested in an environment that matches production as closely as possible. Check:

• Same database version?
• Same environment variables / feature flags?
• Same third-party API versions?
• SSL/TLS configured identically?
• Same CDN and caching setup?

The classic gotcha: tests pass on staging because a feature flag is enabled, but the flag is off in production. Or the staging database has different data than production, so a query that works on staging times out in production with 10x the rows.

5. Smoke test on deployment target#

After deploying to the production (or production-like) environment, run a quick smoke test. This is different from the regression suite. A smoke test checks that the build deployed correctly and the application starts up.

Smoke test items:

• Application loads without errors
• Login works
• Core navigation functions
• At least one critical user flow completes end-to-end
• No console errors on key pages
• API health endpoint returns 200

This should take 10-15 minutes. If any of these fail, stop the deployment. A failed smoke test means something went wrong during deploy, not during development.

6. Performance sanity check#

You don't need a full performance test suite for every release. But a quick sanity check catches regressions:

• Page load time on 2-3 key pages (compare to previous release baseline)
• API response time on the most-used endpoints
• Any new N+1 queries or slow database operations?

If load times increased by more than 20% compared to the previous release, investigate before shipping. Performance problems that are small in staging can be large in production with real traffic.

7. Security basics#

Not a full penetration test, but a baseline check:

• No secrets in the codebase (API keys, passwords, tokens)
• Authentication still works correctly after code changes
• Authorization checks are in place (user A can't access user B's data)
• Input validation on any new forms or API endpoints
• Dependencies updated for known vulnerabilities (check npm audit or equivalent)

If your release changes anything related to authentication, authorization, or user data, invest extra time here.

8. Rollback plan#

Before every release, confirm:

• Can you roll back to the previous version?
• How long does rollback take?
• Are there database migrations that can't be reversed? If yes, what's the plan?
• Who initiates rollback and who approves it?

A release without a rollback plan is a one-way door. Sometimes that's acceptable (major architecture changes, for example). But it should be a conscious choice, documented and approved.

The go/no-go meeting#

With the checklist filled out, you have the data for a go/no-go decision. Here's how to run the meeting efficiently.

Attendees: QA lead, engineering lead, product owner. Three people. More than that and the meeting turns into a debate club.

Duration: 15 minutes. If the checklist is complete, the data speaks for itself. The meeting is for interpreting the data, not generating it.

QA presents: Regression pass rate, new feature test status, known bugs inventory. "We ran 312 test items. 298 passed, 8 failed, 6 blocked. Here are the 8 failures with bug IDs. Three are cosmetic, two are medium severity in the export feature, three are under investigation."

Engineering responds: For each failure, is there a quick fix, a known workaround, or a root cause? "The two export failures are related to the same issue. Fix is ready, needs a rebuild. The three under investigation need another hour."

Product owner decides: Given the data, ship now, ship after fixes, or hold. "Fix the export issue, rebuild, run the smoke test again. Ship today. The cosmetic bugs can go to the next sprint."

The entire conversation is grounded in data from the checklist. Nobody argues from gut feeling because the numbers are right there.

Adapting the checklist to your team#

Small teams (1-3 developers, no dedicated QA)#

You probably don't need formal regression suites or go/no-go meetings. But you do need:

• A quick smoke test after each deploy (5 minutes)
• A list of known bugs you're shipping with
• A rollback plan

Even a simple test management setup with 30-50 test items gives you a smoke test script to run before every release. That's infinitely better than deploying and hoping.

Medium teams (5-15 people, 1-2 QA)#

Use the full checklist. Automate the smoke test if you can. Run the regression suite on the release candidate build, not on a "close enough" staging build. Track your pass rate over time so you have a baseline.

The go/no-go decision might be informal (a Slack thread instead of a meeting), but it should still be documented. "Regression: 95% pass. 4 known lows. Shipping." gives future-you context when something goes wrong and you need to understand what was known at release time.

Large teams (20+, dedicated QA team)#

The full checklist plus: test environment audit, cross-browser/cross-device matrix, accessibility spot check, and formal sign-off from the QA lead. Consider automating checklist generation from your test reporting data so you're not manually compiling numbers before every release.

Making the checklist a habit#

A checklist is only useful if you actually use it. Here's what makes it stick.

Keep it short. If the checklist takes longer to fill out than the testing itself, nobody will bother. One page. Eight sections. Each section is a few bullet points and numbers, not a novel.

Automate what you can. Pass/fail counts should come from your test management tool, not from someone counting manually. In TestRush, test run results are available in real time, so pulling the numbers for the checklist is a glance, not a project. Check how test reporting works for the metrics that matter.

Store checklists with the release. After the release ships, save the completed checklist (or screenshot the test run results). When a bug surfaces in production next week, you can look back and see: did we test this area? What was the pass rate? Was there a known bug we accepted?

Review and prune quarterly. Just like test cases go stale, checklists accumulate items that are no longer relevant. Once a quarter, look at the checklist and ask: did any of these items catch a real problem in the last three releases? If an item never catches anything, consider removing it.

Common mistakes#

1. Running regression on the wrong build. Test the release candidate, not staging. Not "a build from this morning." The specific artifact you plan to deploy. If you rebuild after testing, you need to test again. Builds that are "basically the same" are the source of the worst production bugs.

2. Treating the checklist as bureaucracy instead of information. The checklist isn't about compliance. It's about having enough information to make a good decision. If you're filling it out mechanically without reading the results, you might as well not fill it out.

3. Refusing to ship with any known bugs. Zero bugs is not a realistic release criterion for most teams. The question is whether the remaining bugs are acceptable given the release's value. Ship with three cosmetic issues to deliver a feature users are waiting for? That's usually the right call. Ship with one data-loss bug because you're behind schedule? That's not.

4. No rollback plan. "We'll fix it forward" works until it doesn't. A production issue at 6 PM on Friday with no rollback plan means your team is up all night writing a hotfix. Fifteen minutes of rollback planning prevents hours of crisis management.

FAQ#

What pass rate means a release is ready?#

There's no magic number. Most teams use 95%+ on critical paths and 90%+ overall as a guideline. But the number alone doesn't tell you much. A 92% pass rate where every failure is understood and triaged is safer than 99% where the 1% includes an unexplained failure in the payment flow. Focus on understanding every failure, not hitting an arbitrary percentage.

How often should I update the checklist?#

Review it quarterly. Remove items that never catch problems. Add items when a production incident reveals a gap in your pre-release testing. The checklist should reflect what your team actually needs to check, not a theoretical ideal from a blog post (including this one).

Should automated tests replace the manual checklist?#

Automated tests cover part of the checklist (regression, smoke testing). But environment verification, known bug inventory, rollback planning, and the go/no-go decision are human tasks. Automate the test execution. Keep the decision-making manual. See our manual vs automated testing guide for more on where each approach fits.

How do I handle hotfixes?#

Hotfixes get a shorter version of the checklist: smoke test, targeted testing of the fix, known bugs update, rollback plan. You don't need a full regression run for a one-line CSS fix. But you do need to verify the fix works and didn't break something adjacent. Scale the checklist to the risk of the change.

Track your regression runs and release readiness in one place. Start free with TestRush or try the live demo.