Boundary value analysis

Boundary value analysis rests on an empirical observation about how software breaks. Errors gather at the edges of ranges rather than in their middles, because edges are where somebody had to choose between a comparison that includes the endpoint and one that excludes it. A field accepting one to ninety-nine characters is far more likely to fail at zero, one, ninety-nine or one hundred than at fifty. The technique says to spend the test budget on those points and to stop pretending that a value in the middle of a valid range is telling you anything new.

It pairs naturally with equivalence partitioning, and the two are normally applied together: partitioning divides the input space into classes that should behave identically, and boundary analysis then picks the values at each class edge instead of one from the interior. Applied to a well-understood specification this reduces a theoretically infinite input space to a small, defensible set of cases, and it does so in a way you can explain to somebody asking why a particular number was chosen.

Applying it without overdoing it

• Test the value on each side of every edge as well as the edge itself. The classic off-by-one defect is invisible to a case that only exercises the boundary exactly.
• Remember the boundaries nobody wrote down: the empty string, zero, a negative number, the maximum an integer column can hold, and the point where pagination starts a second page.
• Watch for dates and time zones, where the boundary is a moment rather than a number and midnight in one region is the previous day somewhere else.
• Apply it to outputs too. A report that renders correctly for three rows and breaks at zero or at ten thousand has boundaries on the result, not on the input.

The technique needs a stated range to work from: where the specification never defines the limits, boundary analysis becomes a way of discovering that the requirement is incomplete.