One ticket, five workflows, three defects and one cause

The problem

Five workflows on paper are five separate claims. The only way to know whether they hold together, and whether a decision made in the first one is still visible by the last one, is to run one real ticket through all of them and keep every artefact. examples/artifacts/ is that run, against the same demo site the example suites already test, so every number in it can be checked against the running app.

What it found, workflow by workflow

The ticket: the checkout page should show item total, tax and total, tax is 8%, a developer commented it should be quick.

/qa:refine turned that into five acceptance criteria and five open questions. Two of them are why the story was not ready to build: nobody said whether to round half up, half even or truncate, and nobody said whether the total adds the displayed tax or the raw one. Three developers pick three answers and all three satisfy “correctly”, and that is a cent per order nobody notices until finance closes the month.

/qa:design scored thirteen conditions. Eight are unit rows, three are e2e, one waits on an open question, one is deliberately not automated. It picked its test cart on purpose, $29.99 plus $9.99, because the raw tax of $3.1984 gives $3.19 under truncation and $3.20 under rounding: a cart where both agree would pass either way and tell nobody anything.

/qa:generate wrote and ran the three e2e rows, then broke each one on purpose to confirm it fails for the right reason. It left the eight unit rows unwritten, because this project has no unit layer, and promoting them to e2e would make them slow and fail without saying which of forty things broke.

What exploration found

/qa:explore ran a 55-minute session against a charter the design step produced and found three defects on the live site:

• the back button after confirming an order returns to a live Finish button, and pressing it confirms a second order with no sign anything happened
• emptying the cart in a second tab does not stop the first tab's Finish button from succeeding
• navigating straight to the checkout overview with an empty cart shows Item total: $0 next to Tax: $0.00 and lets a $0.00 order through

All three look like one cause: the cart is read once when a page renders and never re-read when the order is actually confirmed. Validating the cart at confirm time, rather than trusting whatever the page already shows, covers all three at once, which turned three fixes into one.

What the audit found

/qa:audit scored the resulting suite 5s on mechanics, speed, isolation, waiting and having a real assertion behind every test. It scored 2 on layers and 2 on coverage against the requirement, and both twos are the same gap: the highest-risk condition in the entire design, the rounding rule, scored 9 and has no test anywhere, because this suite has no unit layer to put it in. The three defects exploration just found also have no regression test yet, which the audit flags as the cheaper fix to do first, before the underlying bugs are even fixed, so the fix has something to prove itself against.

What it cost

Nothing here was an accident. Every gap traces back to a row in a design document or a line in a generation report: the rounding tests were never promised at the e2e layer, the empty-cart row was deliberately deferred pending an open question. The audit's actual job turned out to be narrower than “find problems”: it is noticing which recorded decisions have not been acted on since, and ranking them by what it costs to leave each one standing.