Boundary value analysis generator and equivalence partitioning calculator
Give it a field name and a valid range, and it produces the seven boundary cases, the three equivalence partitions, and six special values that get missed — each with the reason the case exists.
Name the field, set the valid range, pick integer or decimal. Thirteen test cases with rationale, exported as a Markdown table.
Open the tool — free, no signupBoundary value analysis, properly
Defects cluster at the edges of a range because that is where a developer
writes a comparison, and < versus <= is one
keystroke. BVA tests those edges directly.
For each boundary you test three values: one step below, the boundary itself, and one step inside. Take an order quantity field with a valid range of 1 to 100, integers:
| Input | Expected | Why |
|---|---|---|
| 0 | Reject | Just below minimum — the classic off-by-one |
| 1 | Accept | Minimum boundary, inclusive |
| 2 | Accept | Just inside the lower bound |
| 50 | Accept | Nominal value from the valid partition |
| 99 | Accept | Just inside the upper bound |
| 100 | Accept | Maximum boundary, inclusive |
| 101 | Reject | Just above maximum |
Seven cases. If the developer wrote qty < 100 instead of
qty <= 100, case six catches it. If they wrote
qty > 0 on a field that should start at 1, case two
does.
Equivalence partitioning, properly
Partitioning is the step before boundaries. Divide every possible input into classes where the system should behave identically, then test one value from each class instead of all of them. For the same field: below range (invalid — test with 0), within range (valid — test with 50), above range (invalid — test with 101). Three cases instead of a hundred.
The two techniques are the same idea at different zoom levels: partitions tell you where to test, boundaries tell you exactly which value. Saying that sentence in an interview scores better than reciting the numbers.
The values people forget
The third table covers what neither technique produces on its own: empty
input, non-numeric input, zero, negative one, a wrong-precision value
(1.5 in an integer field), and 999999999 for
overflow and field-length limits. Zero and minus one are marked valid or
invalid based on your actual range, not assumed. These are usually where the
real bugs are — the range logic is often correct while the type and empty
handling are not.
Common mistakes
Testing only the boundaries and skipping the nominal value. If every case sits at an edge, a bug in the ordinary path goes unfound. The midpoint case is not filler.
Using the wrong step size. For a price field valid from 0.01 to 99.99, one step below the minimum is 0.00, not −1. Set the type correctly or the "just outside" values are meaningless.
Assuming boundaries are inclusive. This generator treats min and max as valid because that is the common convention — but read the requirement. If the spec says "under 100", then 100 must be rejected and your expected results invert.
Stopping at the range. A field that correctly rejects 101 and happily accepts an empty string is still broken.
Frequently asked questions
What is boundary value analysis with an example?
It tests the values at the edges of a valid range, where off-by-one errors live. For a field valid from 1 to 100, you test 0, 1, 2, 99, 100 and 101 — one below each boundary, the boundary itself, and one inside — plus a nominal value like 50.
What is the difference between BVA and equivalence partitioning?
Equivalence partitioning divides all inputs into classes that should behave the same and tests one value per class. Boundary value analysis then tests the exact edges between those classes. Partitions tell you where to test; boundaries tell you which value to use.
How many test cases does boundary value analysis produce?
For a single range with inclusive bounds, seven: below minimum, minimum, just above minimum, nominal, just below maximum, maximum, above maximum. This generator adds three partition cases and six special values, for 13 total per field.
Does this work for decimal fields?
Yes. Select decimal and the step becomes 0.01 instead of 1, so a range of 0.01 to 99.99 produces 0.00 and 100.00 as the outside-boundary cases. The special-value table also switches to testing extra precision rather than integer strictness.