RELEASE QA GUIDE
How to QA your website before release
Effective website QA starts with agreeing what must work, testing it in an authorized environment with synthetic data, and producing evidence that lets your team make a clear release decision. This guide outlines a practical, risk-based approach for product and engineering teams.
Define risk and expected outcomes first
Before writing any test, agree on the business-critical journeys and the specific outcomes that define success. “Checkout works” is not a useful expectation; “a returning customer can apply a saved discount code, complete payment with a valid test card, and see the discounted total on the confirmation page” is. Capture these expectations in a living checklist that engineers, product managers, and QA can all reference.
Rank journeys by revenue impact, user volume, regulatory exposure, and recent change activity. A small set of well-understood critical paths is more valuable than broad coverage of low-risk features. Revisit this ranking each release cycle as priorities shift.
Use authorized staging environments and synthetic data
Never test against production customer data without explicit written authorization and a defined scope. Use a dedicated staging or preview environment that mirrors production configuration but contains only synthetic test data. Staging does not automatically prevent real notifications or charges: configure sandbox payment providers and test email inboxes separately, and verify those configurations before running journeys. Prefer synthetic data over anonymized production copies to reduce re-identification risk.
Document which environment, dataset, and credential scope are approved for testing. Describe test accounts and data categories in evidence; never write actual secrets, tokens, or passwords into reports or logs. When test data must resemble real records (for example, to validate migration logic), create it deliberately and delete it after the test window closes.
Prioritize journeys with a concrete checklist
A prioritized journey table keeps scope visible and prevents last-minute surprises. Below is an example format your team can adapt:
| Journey | Risk tier | Expected outcome | Paths to cover | Evidence required |
|---|---|---|---|---|
| New user sign-up and onboarding | Critical | Account created, welcome email sent, dashboard accessible | Happy path; duplicate email error; mobile form validation | Screenshot + trace; email log entry |
| Checkout with discount code | Critical | Discount applied, payment succeeds, confirmation shows correct total | Valid code; expired code; payment retry after decline | Screenshot + network trace; payment sandbox receipt |
| Password reset | High | Reset link delivered, new password accepted, old session invalidated | Valid email; unknown email; link reuse after expiry | Email delivery log; session state check |
| Admin role permission change | High | Role change takes effect within the agreed session policy | Add permission; remove permission; concurrent session refresh | API response + UI screenshot; audit log entry |
Cover happy, error, retry, mobile, and role-based paths
Testing only the happy path misses the failures that cause support tickets and lost revenue. For each critical journey, include at minimum: the successful flow, a meaningful error condition (invalid input, missing permission, upstream failure), a retry or recovery path (payment retry, resubmit after validation error), a mobile viewport check, and any role or permission variant that changes behavior.
Mobile emulation in dev tools is a useful first pass for responsive breakpoints, touch target sizes, and form behavior, but it does not guarantee coverage of audience-critical behavior. Real devices and browsers are needed when sensor access, native keyboards, platform-specific APIs, or rendering differences matter to your users. Plan device testing based on your actual audience and risk profile rather than assuming emulation is sufficient.
Collect repeatable evidence and classify findings
Every reported issue should include the exact steps taken, the expected behavior, the observed behavior, the environment and data used, and supporting artifacts such as screenshots, browser traces, or API logs. If a failure cannot be reproduced, record it as inconclusive and investigate further rather than leaving it ambiguous.
Record a pass only when the agreed expected result was observed and the evidence retained. Other outcomes include confirmed product failure (the system behaves incorrectly under valid conditions), test-environment problem (staging misconfiguration, stale data, flaky selector), inconclusive (behavior observed but not yet explained or reproduced), and untested scope (a journey or variant not exercised this cycle). Each category affects release confidence differently. Missing evidence is not a pass; the product owner weighs remaining uncertainty when deciding whether to release. Record the actual build or version under test when verifiable; if a version mismatch cannot be resolved, mark the result as unverified rather than attributing it to a specific release.
Validate manually before automating
Automation amplifies understanding; it does not create it. Manually walk through each critical journey at least once before encoding it as an automated check. This catches incorrect assumptions, reveals undocumented side effects, and ensures your automated assertions reflect actual business expectations rather than implementation details.
When you do automate, prefer stable selectors tied to user-visible attributes (labels, roles) or explicit test IDs over fragile CSS paths. Keep tests readable as documentation: a future engineer should understand what is being verified without reading the application source.
Discount retry checklist
For checkout flows involving discount codes and payment retries, use this practical checklist with a known basket and expected total:
- Confirm the discount code fixture exists in the staging environment and is active for the test account.
- Apply the code and verify the displayed total updates to the expected discounted amount.
- Trigger a payment decline using the sandbox provider’s designated test card or flag.
- Confirm the UI shows a clear, user-meaningful decline message and preserves the discount and cart contents.
- Retry payment with a valid sandbox card and confirm the discounted total persists on the confirmation screen.
- Verify no duplicate orders, charges, or notification emails were created during the retry cycle.
- Record the sandbox transaction IDs, build version, and timestamp in your evidence artifact.
Accessibility fundamentals without compliance promises
Include basic accessibility checks in your QA process: keyboard navigation for all interactive elements, sufficient color contrast for text, meaningful alt text for images, proper heading hierarchy, and visible focus indicators. These are functional quality attributes, not legal guarantees.
Do not claim WCAG compliance based on automated scans alone. Accessibility conformance requires an assessment against the chosen standard that includes human evaluation. Treat automated results as signals to investigate, not as certification. If formal conformance is a project requirement, engage a qualified accessibility specialist with a defined scope.
Load testing, penetration testing, and production testing need separate authorization and scope. This checklist is a starting point for functional QA, not evidence that a website is secure, fully accessible, or free of defects.
Further reading
- Playwright best practices — general principles for reliable browser automation.
- W3C WAI Easy Checks — introductory accessibility evaluation steps.