Boundary & edge-case testing

How it works

Failures cluster at boundaries rather than spreading evenly across the input space: the edge of the advertised context window, unusually long or short lists, the classic zero/one/many counts that break assumptions baked into training data, and the maximum requested output length where generation is most likely to truncate mid-structure. Boundary testing walks inputs systematically toward these limits — a list that grows from 1 to 10 to 100 items, a context filled to 50%, 90%, and 100% of the stated window — rather than sampling only mid-range cases, because degradation at the edge is often sharp rather than gradual and a handful of comfortable mid-range prompts will never reveal it.

When to use it

Whenever input size, length, or count varies in production and isn't tightly bounded by the application — long-context features, document summarization, list processing, structured-output generation with variable-length fields — and as a standing regression check whenever the advertised context window or output limit changes.

Limitations

Boundaries shift between model versions — a context window that degrades gracefully at 90% capacity in one release may degrade at 70% in the next — so tests need re-validation after every upgrade rather than being trusted as a one-time result. It finds where behavior breaks, not why, so a boundary failure typically needs a follow-up probe to characterize.

Cite this