Pre-Release Testing Checklist: What to Check Before You Ship

Most release problems aren’t hard bugs. They are things nobody checked: a payment webhook still pointing at the test account, a migration that was never run on real data, an old mobile app that breaks against the new API. A checklist won’t make a release safe on its own, but it stops the same avoidable mistakes from coming back.

This is the list we work through before and after a release. Copy it, cut what doesn’t apply to your product, and add what has bitten you before.

1. Know what is shipping

You can’t test a release well if you don’t know what is in it.

• List every change: new features, bug fixes, dependency upgrades, configuration changes.
• Mark the risky ones: anything that touches money, permissions, data structure or a third-party service.
• Agree on the acceptance criteria for each new feature. “Done” should mean the same thing to the developer, the tester and the client.
• Freeze the release candidate. Testing a build that keeps changing means testing nothing in particular.

2. Get the test environment right

Bugs that only appear in production usually come from differences between environments.

• The test environment runs the same versions, configuration and services as production, with test credentials.
• Test accounts exist for every role: a normal user, a second user to check data isolation, an admin.
• The test data looks like real data. An anonymised copy of the production database catches problems that ten neat sample records never will.

3. Test the new work

• Each new feature against its acceptance criteria, including the error cases, not just the happy path.
• Each bug fix: confirm the bug is gone, then test the area around it. Fixes often break their neighbours.
• New screens on real phones and the browsers your users actually have.

4. Run the regression suite

• The critical paths end to end: sign-up, log-in, the main action of the product, payment, password reset.
• The automated regression suite is green. Don’t accept “that test is always red”.
• Anything the release touched indirectly, such as shared components, shared database tables and shared APIs, gets a second look.

5. Check the integrations

Third-party services are where “it worked in test” most often fails.

• Payments in test mode: success, failure, cancellation, refund, and a confirmation that arrives twice or late.
• Emails, SMS and push notifications arrive, with the right content and links.
• Webhooks and callbacks reach the right environment.
• Database migrations run cleanly on a copy of production data, and you know how long they take.
• Older clients still work. If you ship a mobile app, many users will keep the previous version for weeks. The new API must still serve it.

6. The non-functional checks

• Performance: the key pages and API calls are no slower than in the last release.
• Security basics: one user can’t reach another user’s data, admin functions need admin rights, and no secret keys are in the client code.
• Accessibility basics: the main flows work with the keyboard, and text has enough contrast.

7. Prepare the release itself

• Production configuration and environment variables are set and reviewed. A missing variable is one of the most common release failures.
• Risky features are behind a feature flag, so they can be switched off without a new deployment.
• There is a rollback plan, and someone knows how to run it. That includes what happens to data written after the migration.
• Monitoring and error alerts are on, and someone is watching during and after the release.
• The client has signed off on user acceptance testing (UAT).

8. Check production right after the deployment

A release that passed every test can still fail in production. Within minutes of the deployment:

• Walk through the critical paths on the live product, with a real account.
• Watch the error logs and monitoring for anything new.
• Confirm that payments, emails and other integrations work against the live services.
• Report the result. We send a post-deployment report within two hours of the go signal, so everyone knows the release is healthy, or exactly what isn’t.

The short version

• Know exactly what is shipping, and which changes are risky.
• Test on an environment and with data that look like production.
• Test the new work, run the full regression suite, and check every integration.
• Run migrations on real data first, and keep older app versions working.
• Have flags, a rollback plan and monitoring ready before you deploy.
• Check production right after the deployment, and report the result.

Deciding which of these checks to automate? Read manual or automated testing: when to use which.