How can an off-by-one defect survive a suite that already contains boundary tests?

## The question behind the question An interviewer asking this is not testing whether you know what an off-by-one is. They are testing whether you understand that a passing boundary test is only as good as the source the boundary came from and the strength of the assertion at the edge. There are five recurring ways the technique is performed correctly and still finds nothing. ## 1. The edge was read out of the implementation This is the dominant cause. Someone opens the code, finds the comparison, and builds cases around whatever constant is there. The test and the implementation now agree by construction, and the pair will stay green through every refactor. The only way the defect surfaces is when a person compares the behaviour with the written rule — which is precisely the comparison the test was supposed to automate. The discipline is dull and effective: derive each edge from the specification, write the case, and only then look at the code. Where the specification is silent, that silence is a finding to raise, not a gap to fill from the source. ## 2. The written rule is ambiguous *Between 1 and 60*, *up to 500 records*, *no more than a fortnight* — none of these says whether the end value is in or out. A tester reads one way, an implementer reads the other, and both are defensible. The suite then enforces a reading that the code does not share, or, worse, the tester quietly adopts the code's reading to make the case pass. Ambiguity resolved in a test file is not resolved; it belongs in the rule. ## 3. Two rules both claim the edge — the ordering assumption This one is subtle and it is where a real incident usually comes from. A payroll engine bands weekly hours to pick a supplement multiplier, and the bands were written as: 0 to 40, 40 to 60, 60 and above. Notice that 40 appears in two bands and 60 appears in two bands. The engine evaluates bands in list order and takes the first match, so 40.00 lands in the first band and 60.00 lands in the second. The boundary suite was written the same way — by walking the same list top to bottom — and every case is green. Then a change reorders the band list, for an unrelated reason that looks entirely cosmetic. Now 40.00 matches the second band first, and every employee sitting exactly on the standard-week edge is paid a supplement they should not receive. The boundary tests still pass on the new order too, because they were only ever asserting *some* band matched. The defect was never in the comparison. It was in a specification that let two rules own the same value, plus code that resolved the overlap by evaluation order, plus tests that inherited that order as though it were the rule. The lesson is that when an edge value is claimed by more than one rule, the boundary case must assert the specific outcome the written rule demands for that exact value, and the overlap itself should be reported as a defect in the rule set rather than papered over. ## 4. The oracle at the edge is too weak A case that submits 61 hours and asserts only that no error was thrown, or that a page rendered, is not testing the boundary. It passes whether the value was accepted, rejected, silently clamped or rounded down. Boundary cases need the sharpest oracle in the suite because they are asserting a one-step difference — the outcome, the message, the computed figure, not merely the absence of an exception. ## 5. The boundary is not on an input Many real limits apply to values the system derives: a rounded gross figure, a count accumulated over a batch, a proportion computed from two other fields, an index into a table. No form field exposes them, so a suite built by walking the user interface never reaches them. Finding these requires reading the rules for the limits they state about intermediate quantities, then reaching them through inputs chosen so that the derived value lands on its edge — which is often several steps of arithmetic away from anything a user types. ## How you answer the diagnosis version If the interviewer frames it as an incident rather than a quiz, work backwards. State the rule as written. State what the system did at the exact value. Ask where the existing case's edge came from — specification, code, or memory. Check whether any other rule claims the same value. Check what the existing case actually asserted. That sequence usually lands on one of the five in a few minutes, and it separates a candidate who has debugged a live edge case from one who has only read about the technique.