Generate Boundary and Equivalence Partition Test Cases
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
Generate Test Data Fixtures from Schema
Reads a data schema (JSON Schema, TypeScript type, or table description) and returns four explicit fixture groups — happy path, boundary, invalid, and edge cases. Edge group must include Unicode, RTL, emoji, and injection payloads. Output is a ready-to-import JSON file.
Open →Generate Test Cases from Requirements
Given one requirement, the model returns a structured suite of 8-10 test cases — ID, title, preconditions, steps, expected result, priority, and the design technique that generated each case — covering happy path, negative scenarios, boundary values, equivalence partitions, and edge cases.
Open →Create BDD Scenarios in Gherkin
Reads a user story and returns Cucumber-compatible Gherkin scenarios covering happy path, error scenarios, and at least two edge cases. Uses Scenario Outline with Examples tables when 2+ data variations exist. Forbids UI implementation detail in Then steps.
Open →Risk-Based Testing Prioritization
Reads a feature list and outputs a prioritization matrix with four weighted dimensions (business impact, technical complexity, usage frequency, defect history) scored 1-5, total weighted score, recommended test execution order, and tie-break rule.
Open →