Skip to content

Generate Boundary and Equivalence Partition Test Cases

Updated 2026-06-08·basic·Test Design

Reads field constraints (min/max/length/format) and returns boundary and equivalence-partition cases for each — values just inside, on, and just outside the boundary — with technique labels (BVA or EP) per case.

When to use it

  • You have field-level constraints (length, range, format) and need disciplined coverage.
  • You're auditing an existing test suite for missing boundary cases.
  • You're teaching ISTQB techniques and need worked examples.
  • You want to combine with `generate-test-data-fixtures` for full test-data coverage.

The prompt

XML-tagged — best for Claude 4.x

<role>
You are an ISTQB-certified test designer. You apply boundary value analysis (BVA) and equivalence partitioning (EP) with literal precision — "boundary" means on the boundary, not "around it".
</role>

<context>
For every numeric or length constraint, you produce three values: just inside the valid range, on the boundary, and just outside. For every value range, you identify equivalence partitions (one valid, one or more invalid) and produce one representative value per partition.
</context>

<task>
For the field constraints below, generate a table of test inputs covering:
- For each numeric/length constraint: just-inside / on / just-outside triples (per boundary, so a min and a max give 6 values total)
- For each value range or enum: one EP representative per valid partition and one per invalid partition
- Mark each row with the technique label (BVA or EP) and a classification (valid / invalid)
</task>

<input>
Field constraints: {constraints}
</input>

<constraints>
- Table columns: Field, Value, Classification (Valid / Invalid), Technique (BVA / EP).
- For BVA, never use "representative" values — use the literal boundary triples.
- For EP, use realistic values that obviously belong to that partition.
- Include 1-2 hybrid cases per field where BVA and EP intersect (e.g., on-boundary + invalid type).
</constraints>

<output_format>
A Markdown table with the 4 columns above, followed by a 1-2 sentence "Coverage gap" paragraph noting any constraints that have no obvious boundary (e.g., format constraints — no triples possible).
</output_format>

Before writing, list the partitions and boundaries for each field.

Example

Common pitfalls

  • Model picks 'around' the boundary (e.g., 17 and 19) but skips the boundary itself (18). Re-prompt to require literal on-boundary.
  • BVA and EP get conflated — every case labeled BVA. Demand the EP label on partition-representative cases.
  • Composite boundaries (min length AND alphanumeric) get one combined case instead of separate cases per constraint.
  • Model may produce duplicate values for different fields' boundaries — review for accidental overlap.

Tips

  • Feed constraints exactly as written in the spec — don't paraphrase 'between 18 and 99' as '18+', the model loses upper bound.
  • Combine BVA and EP coverage with `generate-test-data-fixtures` to get JSON-ready data plus the analysis table.
  • For composite constraints (length AND format), run the prompt twice — once for length, once for format — and merge.
  • Use this with `decision-table` tool for combinatorial coverage when fields interact.

FAQ

No. BVA catches off-by-one errors at boundaries; EP catches errors specific to a value class (negative numbers, wrong type, invalid format). Real defects hide in both. Use both together for a baseline.

Related prompts

Use with these tools