Establish a release test baseline
Record the build, environment, feature flags, browser matrix, account roles, test data, and third-party modes before testing. Without a baseline, two testers can appear to disagree while using different code, permissions, payment methods, or configuration. Freeze material changes during the pass or log every change explicitly.
Confirm that the environment is safe for the planned actions. Use designated accounts and payment methods, avoid production personal data, and define cleanup for created records, emails, bookings, or transactions. A test that creates uncontrolled side effects is itself a release risk.
Test the critical journey end to end
Start from the way a real visitor arrives, not from a deep link that skips acquisition and session state. Complete signup or sign-in, the product’s first-value action, any payment or publish step, confirmation, and the expected follow-up message. Verify that the result persists after refresh and can be found again.
Test more than the happy path. Use an existing account, expired link, duplicate submission, invalid input, insufficient permission, canceled third-party flow, back navigation, and a retry after failure. Recovery language should explain what happened, what was preserved, and what the user can do next.
- Navigation, deep links, browser back/forward, and refresh
- Authentication, verification, recovery, and role boundaries
- Forms, validation, drafts, duplicate actions, and timeouts
- Payments, confirmation, receipts, refunds, and cancellation
- Email, notifications, webhooks, analytics, and support handoff
Check responsive and accessible operation
Use representative phones, tablets, and desktop widths instead of dragging one browser until the page looks acceptable. Test real touch input, virtual keyboards, zoom, rotation, long names, translated strings, and content that wraps. Confirm that fixed elements do not cover controls and that focus is not lost when layouts change.
Navigate the complete critical path with a keyboard. Review visible focus, meaningful order, headings, labels, error association, color contrast, alternative text, motion preferences, and screen-reader announcements against WCAG 2.2. Automated scanning is a useful baseline, not a substitute for manual and user evaluation.
Verify performance and degraded states
Observe the journey on a slower connection and a less powerful device. The page should communicate progress, avoid layout shifts that move controls, and preserve user input when a request takes longer than expected. Test missing images, failed API calls, offline transitions, and third-party unavailability where the product supports recovery.
Use field or lab performance data for measurable signals such as Core Web Vitals, then pair it with human observation. A technically acceptable loading metric can still feel broken when the only useful content appears late or when a spinner provides no sense of progress.
Make a release decision from evidence
Create a launch gate before testing: which severity levels block release, who can accept a known risk, and what evidence is required for retest. Triage findings by impact and reproducibility rather than by how visually dramatic they appear in a screenshot.
For every blocker, retain the original evidence and record the fix build. Rerun the smallest reproduction first, then the full critical journey. If the issue represents stable product logic, add automated coverage so future launch passes can focus human attention on new and ambiguous risks.
Frequently asked questions
What is the minimum pre-launch QA scope?
Test the primary user journey, its most likely failure and recovery states, supported mobile and desktop environments, accessibility basics, and the operational confirmation after completion.
Should QA happen in production?
Most destructive and payment scenarios belong in a production-like environment. A tightly controlled smoke test in production can verify deployment-specific behavior when accounts, data, and cleanup are explicitly managed.
Who decides whether a bug blocks launch?
The team should define release gates and risk ownership before the test. QA provides evidence; an accountable product or engineering owner accepts or rejects the documented risk.
Primary references
Need an independent pre-launch pass? Create a human QA run.