Six Bugs, One Feature, One Missing Test

Six Highest-priority bugs in five days. One feature. One missing test.

I did not see it while it was happening. I saw it afterwards, reading the tickets in date order — which is the only way this particular pattern ever becomes visible.

What the Chronology Says

A new discount type went into the cart. Then, over five working days, in this order:

• The order could not progress at all.
• The discount was missing from the billing invoice.
• It was missing from the Asset Manager view.
• It was missing from one contract document.
• It was missing from the second contract document.
• An agent could not edit it in the in-life change journey.

Read as a list, that is six defects. Read as a sequence, it is one feature being walked through the flow one surface at a time.

Each fix cleared the current blocker and revealed the next broken surface. Nobody was doing anything wrong. The pattern is invisible from inside a single ticket, which is precisely why it survived a week.

Why the Sequence Matters

A blocking defect at step four guarantees that steps five, six and seven were never executed by anyone.

So the run after the fix is not a retest. It is the first execution of everything downstream.

It rarely gets planned that way. It gets scoped as a retest, timeboxed as a retest, and reported as a retest — "check the bug is gone." And because the plan says retest, the tester goes to the fixed step, confirms it, and stops. The next defect is then found by luck rather than by design, usually by whoever happens to run a longer scenario a day later.

That is how a week-long trickle of Highest-priority tickets clusters on the last day of a sprint.

The Rule

When a feature carries a value — a discount, a charge, a fee, a promotional price — its correctness is not a property of the screen where it is entered. It is a property of every artefact that value reaches afterwards.

One end-to-end scenario. One value. Followed all the way through:

order → billing → asset → documents → in-life change

Not six field checks, run by six people at six different times. One scenario that asks a single question: does this number survive the whole flow?

That scenario takes longer to write than a field check. It replaces six of them, and it fails on day one instead of day five.

How to Build It

The mechanics are unglamorous, and that is the point.

• Pick one value and make it recognisable. A discount amount that appears nowhere else in your test data. When you search the invoice, the asset and the PDF, you want zero ambiguity about whether you are looking at the right number.
• List the surfaces before you test, not after. Every place a monetary value can land: order lines, the billing payload, the asset record, each generated document, each notification, and the in-life journeys that re-read it later.
• Assert on the artefact, not on the screen that produced it. The invoice as billing stores it. The document as generated, opened and read. A green submit screen is not evidence about any of them.
• Include the change journey. Most value-bearing features are tested on creation and never on modification, which is where the last two of those six bugs lived.

The Second Mistake

There is a smaller lesson hiding in that week, and it costs more than it looks.

When the second defect was found — the discount missing from the invoice — it was filed as a clone of the first ticket.

They were two genuinely different defects. Different surface, different cause, different fix.

But the clone link is what your escape data will believe. Six months later, when someone asks how often defects recur in this area, the answer comes back distorted, and nobody remembers why. Link related tickets. Do not clone them to file something new.

Why This Is a Test Design Problem, Not a Discipline Problem

It would be easy to end this with "test more thoroughly." That would be useless advice.

Everyone involved tested what they were given. The requirement described a discount. The story described a cart. The test cases described fields. Nowhere in that chain does anything say follow this number until it stops moving — so nobody did.

The fix is not effort. It is a scenario shape that somebody has to write down once and then reuse for every value-bearing feature that follows.

What is the last feature you tested where the value crossed more than three systems — and did anyone check the last one?