A shop update can finish successfully while leaving an important customer journey broken. The administration screen tells you that the new files are installed; it does not tell you that somebody can choose a product, calculate delivery and receive the right confirmation.
I build a small repeatable test around complete tasks. The scope depends on the shop, but the principle is consistent: verify the behaviour the business needs, not just the absence of an obvious error on the homepage.
Choose a representative purchase
Pick a product that exercises the shop’s ordinary rules. If most sales involve options, a simple item with no options is not enough. If delivery depends on location, include an address that triggers a real delivery calculation. Use fictional or approved test details in an appropriate environment.
Write down the expected item, quantity, price, delivery method and order result before starting. That gives the check something concrete to compare with. “Checkout looked fine” is much less useful than a record that the selected option and total remained correct through confirmation.
Keep the first route short enough to repeat regularly. A sprawling test document nobody can finish is less helpful than a reliable core journey with additional checks chosen according to the change.
Include one recovery path
The successful route is essential, but it is only part of the experience. Try a relevant correction: change a quantity, remove an item, enter an invalid voucher or amend a delivery address. The shop should recover without losing unrelated choices or keeping stale totals.
For payment testing, use the supported test facilities for the configured gateway and make the environment’s mode explicit. Do not casually create real charges merely to prove a button works. A sandbox result also has limits: it checks that test route, not every condition of the production payment service.
I include the confirmation page and customer email in the expected result. The order may exist while its message is missing, or the email may describe a different product option from the one selected. A full task includes the handover after payment.
Separate the environments clearly
A test copy should be recognisable to the person using it. Its payment settings, email destinations and other external connections need deliberate handling so a review does not create unintended customer activity.
Production verification is a separate step after release. I check that the intended version reached the public site and repeat appropriate non-destructive observations there. A successful test on a copy does not establish what visitors are currently receiving.
Where a live transaction is genuinely needed, its authorisation, payment and fulfilment implications should be settled as part of the release process. The test must fit the business rather than leaving staff to discover unexplained orders afterwards.
Save evidence that helps the next review
Record the date, environment, versions, tested route and outcome. If something fails, capture the smallest useful description: the action, expected result and observed result. Avoid putting customer details or payment information into screenshots or general issue notes.
I add targeted checks when an update affects a particular feature. A gallery change calls for image navigation checks; a shipping update calls for representative delivery rules. There is no need to rerun an enormous unrelated exercise after every small change.
Agree in advance what would stop a release and how the previous working state can be restored. Then keep the ordinary test set current as the catalogue and checkout evolve. The value is a repeatable answer to a practical question: can a customer still complete the purchase the shop is designed to support?