The pre-launch QA checklist nobody runs until after the first bad release
The short answer
Before launch, test the journeys that carry revenue on real devices across three price tiers, verify every form and payment path end to end including cash on delivery, run an accessibility pass, and load-test to find the breaking point deliberately rather than discovering it live.
Key takeaways
- Automate the money paths first — coverage percentage is a poor target.
- Test on a mid-range Android on a throttled connection; that is your user.
- Every fixed bug should arrive with a test that would have caught it.
- A flaky test is worse than no test, because it teaches the team to ignore red.
The useful framing is not whether you have bugs — everyone does — but how long passes between a defect being written and someone finding it. Days is manageable. Learning it from a customer is not.
Before you launch
- Every revenue journey, end to end: signup, login, checkout, payment, the core workflow.
- Payments in every path — prepaid, EMI where offered, and cash on delivery including the verification step.
- Forms actually deliver — submit each one and confirm the email *and* the CRM record arrive.
- Real devices across three tiers: low, mid and high-end Android, plus iOS.
- Cross-browser: Chrome, Safari, Firefox.
- Accessibility: automated checks plus a manual keyboard and screen-reader pass on the key journeys.
- Conversion tracking verified — fire each event and confirm it in GA4, the ad platforms and the CRM.
- Load test to the breaking point, if a sale day or campaign launch is coming.
- Redirects, if this replaces an existing site: every old URL with traffic mapped.
- A rehearsed rollback, so a bad release is a minute rather than an afternoon.
What to automate first when you have nothing
- 01The money paths. If these break, the business stops.
- 02The paths you have broken before. Go through the last twenty bug reports and automate the recurrences.
- 03API-level tests for business rules — faster and far more stable than driving the same logic through a browser.
- 04Permission and role tests, especially in multi-tenant products where a mistake is a data incident.
Manual and automated do different jobs
Automate
- Journeys that must never break
- Business rules with clear inputs and outputs
- Anything you have broken twice
- Checks that run on every commit
Keep manual
- Screens still changing weekly
- Exploratory testing — using the product badly on purpose
- Visual and content review
- Anything where the assertion is 'does this feel right'
Automated tests confirm what you thought to check. A human finds what nobody thought of, which is where the serious bugs live. More in test automation strategy and on QA & Test Automation.