How do you decide which boundaries earn a dedicated test case when a rule set has more edges than the budget allows?

## Why this is a leadership question Boundary cases are individually cheap and collectively enormous. Every stated limit is a candidate, every limit has two or three values, and rule sets grow monotonically. On a mature payroll engine an inventory of the written rules produced 1,247 candidate edge values across earnings rules, deduction caps, batch sizes, identifier lengths and period cut-offs. At three-value coverage that is well over three thousand cases, and the regression pack has to finish inside eleven minutes at the 92nd percentile of runs or the team stops trusting it enough to run it on every change. Nobody can have all of it. The question is how you choose, and how you defend the choice to an auditor, a delivery lead and the person who will get paged. ## Step one: make the inventory explicit The argument is unwinnable while the list of edges lives in people's heads. Extract every limit the written rules state, and record for each one: the rule it comes from, the exact limit and whether it is open or closed, the recorded precision, and where the value can be reached from. Include the four kinds that get forgotten — lengths, collection sizes including empty and one, period cut-offs, and limits on values the system derives rather than accepts. The artefact is small, it survives longer than any individual case, and it converts a vague sense that coverage is thin into a countable gap. ## Step two: rank by consequence, not by count Uniform treatment is the failure mode: one case per field, every field the same. Rank instead by what a wrong edge costs. Roughly three tiers work: - **Expensive edges** change money, eligibility, or something irreversible or regulated. A wrong overtime threshold reprices every employee sitting on it, and the correction is manual and public. These get three-value treatment, an explicit oracle on the computed figure, and a check that no second rule claims the same value. - **Ordinary edges** change behaviour a user notices and can work around — a refused upload one record too soon, a truncated field. Two-value treatment at the fastest level that can see the rule. - **Cheap edges** change presentation only. One case, or none, and no shame in none. The ranking is a product conversation as much as a testing one, which is exactly why it belongs to a lead. ## Step three: spend the budget at the right level An edge case does not have to run through the whole system to prove a limit. Most limits are decided in one place, and the case that proves them belongs at the fastest level with visibility of that decision. Reserve the slow, wide level for a small set that proves the value actually travels — that the limit enforced deep in the engine is the same one the outer surface presents. This is where most of the runtime budget is recovered: moving a few hundred edge cases from the widest level to the narrowest usually costs nothing in coverage and returns minutes. ## Step four: cover the class once When forty fields share one length rule, forty sets of length cases test the same code forty times. Cover the shared rule thoroughly once, then spot-check that each field is wired to it. Parameterise from a data table so that adding a value is a row rather than a new case, and so the inventory and the suite can be diffed against each other. ## Step five: re-rank from evidence, and be honest about what is not known The claim that some fixed proportion of defects lives at boundaries is repeated confidently and is not settled — published figures vary widely across studies with different systems, defect definitions and counting rules, and no single multiplier deserves to be quoted as fact. Say so in an interview; a lead who cites a precise industry number for boundary defect density is quoting folklore. What you can measure is local. Keep the escaped defects that turned out to be edge defects, tag them with the rule and the tier that rule was in, and review the tiering periodically. A rule that has produced two escapes belongs in the thorough tier whatever its original ranking; a tier-one rule that has been stable across many releases and many changes can be thinned. That loop is the actual answer to the question, because it replaces a static guess with a policy that gets better with age. ## What good sounds like A strong answer names the inventory, ranks by consequence, moves cases to the cheapest level that can see the rule, deduplicates by class, and closes the loop with the team's own escape record — while declining to pretend there is a published constant that settles how much boundary testing is enough.