Software Testing and QA Checklist Before Launch: What to Verify Before You Go Live

Launch day is a poor time to discover that password reset emails never arrive, that the checkout fails on one browser, or that the database cannot be restored. Most of these are not exotic bugs; they are things nobody checked. A disciplined test pass before go-live is cheap insurance, and it does not require a large QA department.

Use this checklist as a starting point and adapt it to your product. The aim is to cover the main ways a launch fails: broken core flows, bad data, slow performance, weak security and no plan when things go wrong.

1. Agree what "ready" means

• A written list of must-work journeys, such as sign-up, login, purchase, booking, invoice, and each user role.
• Acceptance criteria for every feature in scope.
• A severity scale: blocker, major, minor, cosmetic. Decide in advance that blockers and majors stop the launch.

2. Functional testing

• Walk through every core journey end to end, as each type of user.
• Test both the happy path and the failures: wrong password, empty form, expired link, duplicate submission, interrupted payment.
• Check validation on every form: required fields, formats, length limits, special characters.
• Check emails and notifications are delivered, correctly addressed and render properly, and that they do not land in spam.
• Test roles and permissions: users must not see or change anything they should not.
• Verify integrations (payments, maps, messaging, accounting) in the provider's test mode, then confirm live credentials and webhooks.

3. Regression testing

Each change can break something that used to work. Keep a short list of critical checks that you run after every significant change, and automate the ones you repeat most. This ties naturally to a build pipeline; see CI/CD and DevOps basics for small teams.

4. Usability and content

• Have two or three people who were not involved in the build attempt the main tasks without help. Watch where they hesitate.
• Check wording, error messages, empty states and loading states.
• Proofread legal pages, pricing and contact details.

5. Compatibility

• Test the latest versions of the major browsers and at least one older version if your audience needs it.
• Test on real phones and tablets, in portrait and landscape, on slower connections.
• For mobile apps, test on several OS versions and screen sizes, and test interruptions such as calls and low battery.

6. Accessibility basics

• Everything usable by keyboard, with visible focus.
• Sufficient colour contrast and text that can be resized.
• Meaningful labels on form fields and descriptions on images.

7. Performance and load

• Measure page load and key action times on a realistic connection and dataset.
• Run a load test at your expected peak, plus a margin, for example a launch campaign. Watch error rates and database behaviour, not only averages.
• Find and fix obviously slow queries and oversized images.

8. Security

• HTTPS everywhere; secure cookies; sensible session expiry.
• Passwords hashed; rate limits on login and sensitive endpoints.
• Protection against common web vulnerabilities such as injection, cross-site scripting and broken access control.
• No secrets, test accounts or debug modes left in production.
• Dependencies updated and checked for known vulnerabilities.

The security checklist for business software goes deeper, and our security page describes how we approach it.

9. Data

• If migrating existing data, reconcile counts and sample records between old and new systems.
• Confirm no test data will appear in production.
• Check that exports, reports and totals match known values.
• Confirm privacy handling: consent, retention and deletion requests.

10. Release readiness

• Backups are running, and a restore has been tested at least once.
• Monitoring and alerting are live: uptime, errors, performance.
• A rollback plan exists and has been rehearsed.
• Analytics and conversion tracking are firing correctly; see how to track marketing leads from first click to revenue.
• Support channels, contact forms and the escalation contact are ready.
• Someone is on call for the first days after launch.

Who should test

Developers test their own work, but they are poor at seeing their own blind spots. Add an independent tester, ideally someone who follows the written test cases and also explores freely. Finish with user acceptance testing by the business owner or real pilot users, against the acceptance criteria. A small team can combine these: developers write automated tests for critical logic, a QA engineer or colleague runs exploratory and regression passes, and the product owner signs off.

Plan a soft launch

Where possible, release to a small group first. Real users find problems test plans miss, and a limited audience limits the damage. Then use the measures in what to measure in the first 90 days after launch to guide improvements. Our delivery teams include QA as standard; see MVP development for how we plan it.

Turn your idea into a plan

Getting ready to launch? Start with a Business Blueprint covering customers, revenue model, MVP scope, technology and roadmap. Paste something like this into the Blueprint tool:

I am about to launch [product] with these core journeys: [list]. We have [team size] people. Suggest an MVP launch plan, a test plan covering the critical flows and a soft-launch approach.

Or talk to us first, and read about the Business Blueprint.