What this example is
This is an authored specification, not an executed test and not a client result. The product, coupon code and zones are invented. It shows the shape of a script: each case names the journey, the setup and the expected result, written before anything is run. A real script is built around your products, your destinations and your payment method.
- Runs on a staging copy with payments in test mode and customer email redirected.
- The same eight cases are run before and after the updates under test.
The matrix
Run the cases in order. For each, record the order number, status, total, stock figure and a screenshot, and note anything that differs from the expected column.
If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.
ID Journey Setup Expected result
T1 Guest, simple product Test card, address zone A Order Processing; stock -1 once; total = price + zone A rate
T2 Signed-in, variable product Size M, colour Navy Cart holds the Size M / Navy variation; correct price
T3 Shipping, zone B Postcode inside zone B Zone B methods and costs as in the destination table
T4 Shipping, not served Address in an excluded region No shipping method shown
T5 Coupon Code SPRING10 on one product One discount line; total as expected
T6 Declined payment Test decline card No paid order; stock unchanged or returned
T7 Confirmation email Test inbox One order email with correct lines and total
T8 Gateway confirmation, resent Provider log; resend T1 event Event delivered, order moves on; after the resend no second status change, stock unchangedWhy these cases
T1 and T2 carry the main buying path and the variation match. T3 and T4 test that shipping zones give the right result and the right refusal. T5 covers the one coupon the store actually uses. T6 checks that a failure leaves no paid order behind, which matters because failed orders return stock. T7 checks the email a customer actually receives. T8 tests the part that fails silently: whether the provider's confirmation reaches the store, and whether a resent delivery is harmless, since duplicates can occur and are identified by event ID.
How a result is read
A case passes only if every part of its expected result holds. A case that fails after an update and passed before it points at the update, and the next step is to isolate which component changed, on the copy, by switching to a default theme and deactivating other plugins one at a time. A pass on all eight says those cases worked on the copy with those updates. It does not say live checkout works, so one real order is placed on live after updating.
- Pass: every part of the expected result holds.
- Fail: record what happened instead, with evidence.
- Not run: say why; it is not a pass.
What the matrix leaves out
It leaves out performance, security checks, accessibility, subscriptions and any custom plugin behaviour. Add a case for each journey that carries money in your store, and remove cases that no one would notice failing. The standing service this shape comes from runs a script of up to eight cases, so this matrix is the largest shape it covers.
Sources and limits
- WooCommerce documentation: Order statuses Checked 2026-10-11.
- Processing means paid with stock deducted, Pending payment means no payment has arrived, and Failed or Cancelled orders return stock to inventory.
- WooCommerce documentation: How to test for conflicts Checked 2026-10-11.
- A staging clone or a backup protects the live store while testing, and browser caching should be disabled while testing.
- Stripe documentation: Receive Stripe events in your webhook endpoint Checked 2026-10-11.
- The Event deliveries tab lists events as Delivered, Pending or Failed with the HTTP status code, and events can be resent from the Dashboard.
- Duplicate deliveries should be identified by event ID.