If equivalence partitioning reduces an infinite input space to a small set of classes, boundary value analysis (BVA) tells you which inputs to actually pick from each class. The answer is almost always the same: the values right at the edges. Bugs love boundaries, and BVA is the technique that systematically points at them.
Why bugs cluster on the edge
Consider a field that accepts integers from 1 to 100. The internal code probably contains a comparison like if (value >= 1 && value <= 100). The most common bugs in this code are:
- Off-by-one errors. Someone wrote
>instead of>=, so the boundary value 1 is rejected. Or<instead of<=, so 100 is rejected. - Inclusive/exclusive confusion. The spec said "up to 100" but the developer interpreted that as "less than 100."
- Type coercion. The boundary check happens after a cast, and the cast does something subtle at the extremes.
A test with the value 47 will not catch any of these. A test with 1 or 100 might. A test with 0, 1, 100, and 101 almost certainly will.
The standard BVA pattern
For any range with a minimum min and maximum max, BVA suggests testing five values:
min - 1(just below)min(the lowest valid value)- A value somewhere in the middle (a representative valid input)
max(the highest valid value)max + 1(just above)
Boundary values around a 1-100 range
For our 1-to-100 example, that means testing 0, 1, 50, 100, and 101. Five tests, and you have covered:
- The valid lower edge.
- The valid upper edge.
- A normal middle value.
- The just-invalid lower neighbour.
- The just-invalid upper neighbour.
This catches off-by-one errors at both ends and confirms the middle works as expected.
Beyond simple ranges
BVA generalises to anything with a defined edge:
- String length. If a field allows 6 to 12 characters, test strings of length 5, 6, 12, and 13.
- Array size. If a feature handles up to 50 items, test 0, 1, 49, 50, and 51 items.
- Time windows. If a discount runs from January 1 to January 31, test December 31 23:59:59, January 1 00:00:00, January 31 23:59:59, and February 1 00:00:00.
- Numeric precision. If a field accepts numbers up to two decimal places, test 1.99, 2.00, 2.001, and 2.999.
- Currency. Test the smallest positive amount (e.g. 1 cent), the largest expected amount, zero, and negative amounts.
Even non-numeric domains have boundaries. A form that triggers a warning at "more than 5 failed login attempts" has a boundary at 5: test exactly 5 attempts (no warning?) and exactly 6 (warning?).
Special boundary values worth always testing
Beyond the spec-defined edges, certain inputs are notorious for tripping up code:
- Zero, especially in fields that support negative and positive values.
- Negative numbers in fields that "shouldn't get them" but might.
- Null / empty strings, especially after the field has had content.
- Maximum integers (32-bit, 64-bit) for any numeric field.
- Unicode boundary cases — surrogate pairs, combining characters, RTL text.
- Time zone edges — midnight, daylight saving time transitions, leap seconds.
- Rate limits and quotas — what happens at exactly the limit?
A useful rule: any "magic number" that appears in the requirements is a boundary worth testing.
BVA + partitioning together
Partitioning tells you which classes to test; BVA tells you which value to pick from each class. Together they form the bedrock of formal test design:
- Partition the input space.
- For each class, pick the boundary value plus one middle value.
- Test each.
This combination is taught in every QA certification course and used implicitly by every experienced tester, even those who would not use the formal names.
What you should walk away with
BVA is a small idea with disproportionate impact. If you only learn one test design technique, learn this one — it will pay back its weight in caught bugs every release. The next lesson tackles a more complex scenario: when behaviour depends on the combination of multiple inputs. That is the territory of decision tables.