Quality assurance checks before a software launch
A risk-based pre-launch QA plan covering the core journey, failure states, permissions, integrations, accessibility, and the first days after release.
By Aleksej Djokic ยท
Test the promise and the boundaries
Quality assurance is more than checking whether buttons work. Start with the promise the product makes, then test the conditions that make that promise fail: missing data, invalid input, slow networks, revoked access, duplicate actions, and changes between devices or sessions.
A practical test pass
Run the critical journeys
Test the primary task from a clean account through completion, including confirmation and the next return visit.
Test the unhappy paths
Cover validation, empty results, server errors, timeouts, refreshes, back navigation, duplicate clicks, and interrupted payments.
Test identity and data boundaries
Verify roles, account recovery, deletion, tenant separation, and that private data is not exposed in URLs, logs, or shared views.
Test the shipped environment
Use the release build, production-like configuration, representative browsers and devices, and realistic content, rather than only a local development setup.
Include before sign-off
- Keyboard and screen-reader checks for important flows
- Slow connection and small-screen checks
- Integration rate-limit and outage behavior
- A list of known issues with owners and release decisions
- A support and monitoring plan for the first release window
The tradeoff
Testing everything equally is not practical. Risk-based QA spends the most attention where failure would harm users, money, trust, or the launch decision. It is a prioritization method, not permission to ignore lower-risk defects without recording them.