Boundary and combination design

How it works

Classic test design techniques — equivalence partitions, boundary values, decision tables, pairwise combinations — are mechanical once the inputs are known, but finding the inputs and their real limits is the slow part. The model reads the rules wherever they live — validation code, API schemas, configuration files, policy documents — and lists the parameters, their partitions and their edges, including the less obvious ones: the limit that differs per customer tier, the date that changes behaviour at month end, the combination of two flags that nobody documented. For the combinations themselves, a deterministic pairwise or combinatorial tool is still the right generator; the model's job is to prepare its input and explain the result.

When to use it

Forms, calculations, pricing, eligibility and permission rules; configuration-heavy products where the option space is large; when rules are scattered across code and documents; and when a decision table needs building and the rules haven't been written down in one place.

Limitations

Boundaries the model infers from text may not match the boundaries the code actually enforces, and the gap between the two is exactly what testing needs to find — so the inferred values are candidates, not facts. Asked to generate combinations itself rather than prepare them for a tool, the model gives inconsistent coverage and can't guarantee pairwise completeness. Implicit limits — database column widths, integer sizes, timeouts — rarely appear in the material it reads.

What you still own

Checking the inferred rules against the code or the system, and choosing how much combinatorial coverage the risk justifies.

Related evals

Cite this