Substitute One Real Price Into the Rule Before You Test the System

The pricing precedence was written down clearly: 100% adjustment, then the standard bundle adjustment, then base price.

Everybody read it. Nobody ran it.

One Product From the Actual Catalogue

Take a real product. List price £51. The bundle carries its own adjustment of £35.

Apply the precedence in the order the design gives it.

Start at £51. Apply the 100% adjustment — you are now at zero. Apply the bundle's £35 adjustment — you are now at minus £35.

A monthly price of minus £35. Every month, for the life of the subscription, the company pays the customer.

That number came out of a specification that had been read and approved, using a product from the catalogue the specification is about. It took less time to produce than reading the paragraph that produced it.

The Second Formula Nobody Noticed

The negative price is the loud finding. The quiet one is more important.

The sibling story's expected invoice lines assume something different: that the 100% is taken off the net price, after the bundle adjustment, not before it. Run that order and the arithmetic behaves — you land on zero and stay there.

So there are two formulas in circulation for one promotion. They are not labelled as alternatives. Neither document acknowledges the other. One lives in a precedence list, the other lives implicitly in a set of expected invoice lines, and the only thing that makes them visibly different is putting a number through both.

Read as prose, they are the same rule described twice. Read as arithmetic, they disagree by £35 a month.

Why a Precedence List Never Gets Executed

This is the mechanism, and it is worth naming precisely.

A precedence list is a formula wearing the clothes of an ordering statement.

"100% adjustment, then the standard bundle adjustment, then base price" presents itself as a statement about sequence. Sequence statements invite a particular kind of review: does this order sound right? Should the promotional adjustment come before or after the bundle one? That is a sensible-sounding question, it can be discussed for twenty minutes, and it can be answered confidently by people who never touch a digit.

Formulas invite a different kind of review: run it.

Nobody consciously decided not to evaluate the rule. The format simply never asked to be evaluated. That is why this survives refinement, design review and sign-off intact — every reviewer performed the review the artefact requested.

There is a specific trap inside this one, too. A 100% adjustment leaves nothing to adjust. Once a percentage of that size appears anywhere in an ordered list of adjustments, the steps after it are operating on zero, and any absolute amount among them goes straight through into negative territory. Percentages and fixed amounts in one precedence chain is the shape to be suspicious of.

The Rule

Arithmetic-test the specification before you test the system.

Substitute one real catalogue value into every pricing rule you are handed and look at what comes out. Not to verify the price. To find out whether the rule is capable of producing a legal one.

A rule that cannot produce a legal number has already failed. It fails for free, before an environment exists, before a build exists, before anyone has spent a sprint implementing it faithfully.

And faithful implementation is the danger here. Nothing in that precedence list is ambiguous. A developer reading it will build exactly what it says, correctly, and the correctness of the build is what makes the defect expensive — there is no bug in the code to find, so the tester chasing it finds a system that matches its specification perfectly and reports nothing.

How To Do It in Forty Minutes

• Pick the most-adjusted product in the catalogue, not a clean one. Do not test the rule with £100 and a single 10% discount. Choose the product carrying a promotional adjustment, a bundle adjustment and a base price at once, because interaction between adjustments is the entire risk and a simple product has no interaction to expose.
• Take every rule to a single number and write the number down. Not "the order looks right." A number, in pounds, that a customer could be charged. If you cannot reach a number, the rule is incomplete, and incompleteness discovered at this stage is a paragraph to fix rather than a re-plan.
• Sanity-check the number against what a business can legally and commercially charge. Negative is the obvious failure. So is a promotional price above list, a free month that is not free, a rounding that lands on a third of a penny, and a total that no invoice template could display.
• Then compare it against every other artefact that states an expected amount. Sibling stories, expected invoice lines, worked examples in the design. Where two artefacts disagree, the disagreement is almost always an unstated difference in ordering — and ordering differences are invisible in prose and unmissable in arithmetic.

Four steps, one product, no system access.

Why This Gap Sits Where Nobody Stands

Business analysts review pricing rules for commercial intent. Developers implement them. Testers test the output of the implementation against the rule.

Every one of those roles takes the rule as given. The rule itself — as a piece of arithmetic that either works or does not — is reviewed by nobody, because checking it is neither analysis nor development nor testing in the usual division of labour.

It falls to whoever is willing to open the catalogue and do a subtraction. In practice that is the tester, and it is the highest-yield forty minutes available before a build starts, because the finding is not a defect report against code. It is a defect report against a document, and documents are cheap to correct while they are still documents.

Which pricing rule on your current project has never had a real number pushed through it?