A website can look finished long before its important journeys work reliably. The useful question before launch is not simply whether each screen looks right. It is whether a customer can reach the outcome they came for.
Start with the journeys that matter
Choose the tasks with the greatest user or business impact: creating an account, sending an enquiry, making a booking, buying a product, or changing account details. Write down the expected outcome for each journey.
Follow each one from the entry point to the final confirmation. Include the emails, redirects, and integrations that make the experience complete. A successful button click is not the same as a successful order.
Challenge the assumptions
Try empty fields, unexpected characters, repeated clicks, going back, and refreshing at an awkward moment. Ask what happens when a user changes their mind halfway through.
For checkout, revisit the total after a discount, quantity change, or different delivery option. Use a suitable sandbox and controlled test data. Avoid creating real payments or customer orders while testing.
Agree realistic coverage
Choose browsers and screen sizes based on your audience and supported product. On smaller screens, check that the primary action remains visible, messages are readable, and important content is not clipped.
Record exactly what you checked. A claim that the website works everywhere is less useful than a clear account of the environments and journeys covered.
Report what helps the team act
A useful finding includes the environment, reproduction steps, expected and actual behavior, and evidence where it adds clarity. Explain the user impact, then agree a priority based on reach and business risk.
For example, a discount that disappears after a delivery change may affect conversion and trust. That is an illustrative scenario, not a client case study. The priority of a real finding depends on how often it occurs and whom it affects.
Retest the full journey
After a fix, repeat the failing steps and check the nearby behavior that could have changed. Keep any remaining limits visible in the release summary.
Testing gives your team evidence for a decision. It does not replace a decision or promise that every possible issue has been found.
