Free tool
Boundary value and equivalence partition generator
Say what a field accepts, range by range, and get the values worth testing — one per partition, every boundary value, or every boundary value and its neighbours — along with the values your specification forgot to mention.
Start from an example
Partitions: what the specification says happens
| From | To | What happens | Valid | Remove |
|---|---|---|---|---|
Everything is calculated in your browser.
Enter only what the specification states. Values below and above it, and any gap between two partitions, are added as partitions of their own. Leave From or To empty when there is no limit on that side. The step is the smallest difference the field can hold: 1 for whole numbers, 0.01 for money.
Partitions tested (5)
- Below 18 · 17 and below · added
- Young driver surcharge · 18 to 24
- Standard premium · 25 to 74
- Referred to underwriter · 75 to 99
- Above 99 · 100 and above · added
| ID | Value | Expected | Why |
|---|---|---|---|
| BVA2-01 | 17 | invalidBelow 18 | Highest value of Below 18 |
| BVA2-02 | 18 | validYoung driver surcharge | Lowest value of Young driver surcharge |
| BVA2-03 | 24 | validYoung driver surcharge | Highest value of Young driver surcharge |
| BVA2-04 | 25 | validStandard premium | Lowest value of Standard premium |
| BVA2-05 | 74 | validStandard premium | Highest value of Standard premium |
| BVA2-06 | 75 | validReferred to underwriter | Lowest value of Referred to underwriter |
| BVA2-07 | 99 | validReferred to underwriter | Highest value of Referred to underwriter |
| BVA2-08 | 100 | invalidAbove 99 | Lowest value of Above 99 |
These 8 values catch 18 of 20 boundary mistakes the ISTQB syllabus describes.
Between Below 18 and Young driver surcharge: boundary one step too low, so 17 is handled as Young driver surcharge
Partitions missed2-value BVA caught3-value BVA caught
Between Below 18 and Young driver surcharge: boundary one step too high, so 18 is handled as Below 18
Partitions missed2-value BVA caught3-value BVA caught
Between Below 18 and Young driver surcharge: boundary missing, so both are handled the same way
Partitions caught2-value BVA caught3-value BVA caught
Between Below 18 and Young driver surcharge: "≤ 17" written as "= 17", so the rest of Below 18 is handled as Young driver surcharge
Partitions caught2-value BVA missed3-value BVA caught
Between Below 18 and Young driver surcharge: "≥ 18" written as "= 18", so the rest of Young driver surcharge is handled as Below 18
Partitions caught2-value BVA caught3-value BVA caught
Between Young driver surcharge and Standard premium: boundary one step too low, so 24 is handled as Standard premium
Partitions missed2-value BVA caught3-value BVA caught
Between Young driver surcharge and Standard premium: boundary one step too high, so 25 is handled as Young driver surcharge
Partitions missed2-value BVA caught3-value BVA caught
Between Young driver surcharge and Standard premium: boundary missing, so both are handled the same way
Partitions caught2-value BVA caught3-value BVA caught
Between Young driver surcharge and Standard premium: "≤ 24" written as "= 24", so the rest of Young driver surcharge is handled as Standard premium
Partitions caught2-value BVA caught3-value BVA caught
Between Young driver surcharge and Standard premium: "≥ 25" written as "= 25", so the rest of Standard premium is handled as Young driver surcharge
Partitions caught2-value BVA caught3-value BVA caught
Between Standard premium and Referred to underwriter: boundary one step too low, so 74 is handled as Referred to underwriter
Partitions missed2-value BVA caught3-value BVA caught
Between Standard premium and Referred to underwriter: boundary one step too high, so 75 is handled as Standard premium
Partitions missed2-value BVA caught3-value BVA caught
Between Standard premium and Referred to underwriter: boundary missing, so both are handled the same way
Partitions caught2-value BVA caught3-value BVA caught
Between Standard premium and Referred to underwriter: "≤ 74" written as "= 74", so the rest of Standard premium is handled as Referred to underwriter
Partitions caught2-value BVA caught3-value BVA caught
Between Standard premium and Referred to underwriter: "≥ 75" written as "= 75", so the rest of Referred to underwriter is handled as Standard premium
Partitions caught2-value BVA caught3-value BVA caught
Between Referred to underwriter and Above 99: boundary one step too low, so 99 is handled as Above 99
Partitions missed2-value BVA caught3-value BVA caught
Between Referred to underwriter and Above 99: boundary one step too high, so 100 is handled as Referred to underwriter
Partitions missed2-value BVA caught3-value BVA caught
Between Referred to underwriter and Above 99: boundary missing, so both are handled the same way
Partitions caught2-value BVA caught3-value BVA caught
Between Referred to underwriter and Above 99: "≤ 99" written as "= 99", so the rest of Referred to underwriter is handled as Above 99
Partitions caught2-value BVA caught3-value BVA caught
Between Referred to underwriter and Above 99: "≥ 100" written as "= 100", so the rest of Above 99 is handled as Referred to underwriter
Partitions caught2-value BVA missed3-value BVA caught
Each row is a way of putting a boundary in the wrong place. A value catches it when the mistake would change how that value is handled. Code can be wrong in other ways that no value from the specification reveals.
What it generates
The three sets follow the definitions in the ISTQB Foundation Level syllabus (version 4.0, sections 4.2.1 and 4.2.2), because that is what most teams, and every certification exam, mean by these words.
- Equivalence partitioning splits the values into groups the system should handle the same way, and tests one value from each group, invalid groups included. It proves each rule exists; it says nothing about where the rules meet.
- 2-value boundary value analysis tests the lowest and highest value of every partition. For “18 to 64 is accepted” that is 17, 18, 64 and 65: each edge, and the value just across it.
- 3-value boundary value analysis tests every boundary value and both of its neighbours. The syllabus counts three values per boundary value, not per boundary, so the edge between 17 and 18 gives four values — 16, 17, 18 and 19 — and not three.
Why 3-value is worth the extra cases
The syllabus gives the reason in one example: a rule “x ≤ 10” implemented as “x = 10”. The 2-value set, 10 and 11, passes on that code — 10 is still accepted, 11 is still rejected. Only 9, a neighbour that 3-value analysis adds, shows that everything below 10 has stopped working. Open the table under the results to see, for your own field, which mistakes each set catches and which it lets through. The table is worked out from your partitions, not written in advance.
The step decides what “next to” means
The value next to 10.00 is 10.01 for a money field and 11 for a count. Get this wrong and the neighbour you test is in the same partition as the boundary, which tests nothing. Set the smallest step the field can hold, and the generator does all of its arithmetic in whole numbers of that step, so an amount never turns into 10000.009999999.
For text, choose measured by its length. A length can’t go below zero, so the empty string becomes a boundary value in its own right — which it is: an empty required field and a one-character one are often handled by different code.
Gaps are questions, not errors
“1 to 9 full price, 11 to 49 ten percent off” says nothing about 10. When the partitions you enter leave a hole, the generator tests the hole as a partition of its own and tells you what to ask. That is often the most useful output: whatever the code does with a value nobody decided about, nobody has checked it. Overlaps are the opposite problem — one value handled two ways — and the generator refuses them until you decide.
From one field to a whole form
These techniques pick values for one field at a time. A form combines several, and testing every combination quickly becomes impossible. Combine with other fields opens the pairwise test case generator with this field’s values already entered, invalid ones marked so that no generated case contains two of them — a case with two invalid inputs can’t tell you which one it rejected.
What it doesn’t do
- Unordered values have no boundaries. Countries, payment methods and user roles can be partitioned, but there is no “next” country, so boundary analysis doesn’t apply. List those in the pairwise generator directly.
- Dates and times aren’t supported yet. Their boundaries depend on calendars and time zones — the last day of February, the hour a clock skips — which deserves more than a number field.
- An open-ended partition is represented ten steps past its boundary. Any value in it would do; if a particularly large or negative value matters to you, add it yourself.
How these values turn into written test cases, with the results we saw on a real checkout form, is in how to write effective test cases.