Synthetic Industry

Inspectable example · updated 2026-10-11

Synthetic worked example: an eight-case WooCommerce test-order matrix

Inspect an invented test-order script with the expected result for each journey, written before running it on a staging copy.

An example, not a customer case study. Scope and evidence limitations are described below.

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 unchanged

Why 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