Boundary Value Analysis
In the last lesson, Equivalence Partitioning told us that RecipeBox's "Prep Time (minutes)" field
has a valid partition from 1 to 180. If you picked a "representative value" from that partition at
random, you might type 73 and move on. But experienced testers know from hard-earned
experience that developers almost never write a bug in the middle of a range — they write it at the
edges. A developer who means "1 to 180 inclusive" might accidentally code > 180
instead of >= 180, silently allowing 180 minutes to be rejected, or 181 to sneak
through. Boundary Value Analysis (BVA) is the technique built entirely around this
observation: test the edges of your valid ranges, not just the middle.
What Is Boundary Value Analysis?
BVA says that for any range-based input, the values most likely to reveal a bug are the ones sitting
right on — or just next to — the boundary between valid and invalid. For a range with a minimum
value min and a maximum value max, the classic set of boundary values to
test is:
min - 1— just outside the valid range on the low end (should be rejected)min— the lowest valid value (should be accepted)min + 1— just inside the valid range (should be accepted)max - 1— just inside the valid range on the high end (should be accepted)max— the highest valid value (should be accepted)max + 1— just outside the valid range on the high end (should be rejected)
Why Bugs Cluster at Boundaries
Boundary bugs are almost always caused by what's called an "off-by-one" error — a
developer uses the wrong comparison operator, like < instead of <=,
or writes a loop or check that is one unit too strict or too loose. These mistakes are extremely
common because boundaries are exactly where a programmer has to make a deliberate choice about
"inclusive" versus "exclusive," and it's easy to get that choice wrong once and never notice, since
the middle of the range will always work fine regardless.
Worked Example: Testing RecipeBox's Prep Time Boundaries
The requirement is still: prepMinutes must be a whole number from 1 to 180, inclusive. That
gives us min = 1 and max = 180. Applying the standard BVA formula:
| Test Value | Position | Expected Result | Why It Matters |
|---|---|---|---|
0 | min - 1 | Rejected | Catches a missing or wrong lower-bound check |
1 | min | Accepted | Confirms the lowest valid value isn't accidentally excluded (e.g. a stray > instead of >=) |
2 | min + 1 | Accepted | Confirms normal behavior just inside the range |
179 | max - 1 | Accepted | Confirms normal behavior just inside the range |
180 | max | Accepted | Confirms the highest valid value isn't accidentally excluded (e.g. a stray < instead of <=) |
181 | max + 1 | Rejected | Catches a missing or wrong upper-bound check |
Six test values, and together they cover exactly the region of the field's logic where an off-by-one
mistake would actually show up. If RecipeBox happens to accept 181 as valid, or reject
180, you've found a real, specific, reproducible bug — and BVA is what pointed you
straight at it instead of leaving it to luck.
BVA and Equivalence Partitioning Work as a Pair
-5 (invalid-low partition), 0, 1, 2 (the low boundary), 90
(a mid-range valid representative), 179, 180, 181 (the high boundary), 500
(invalid-high partition), and "abc" (non-numeric partition) — around ten values that
give you strong confidence in the field, instead of guessing.
Boundaries Aren't Just for Numbers
BVA applies anywhere there's a defined limit, not only numeric ranges. If RecipeBox's recipe
title field has a maximum length of, say, 100 characters, the boundary values to test
are titles of 99, 100, and 101 characters. If the "Add Recipe" screen allows a maximum of 50
ingredients per recipe, the boundaries are 49, 50, and 51 ingredients. The same "one under, exactly
at, one over" pattern applies every time a spec says "at most," "at least," "no more than," or
gives you a min/max range.
Common Mistakes With Boundary Value Analysis
- Testing only the valid boundary (min, max) and skipping min-1/max+1. The invalid side of the boundary is just as important — that's often where the actual defect lives.
- Forgetting BVA applies to output values and time-based limits too — session timeouts, retry counts, pagination page sizes — anywhere a system defines an edge.
- Confusing "boundary" with "extreme." BVA isn't about trying the biggest or weirdest number you can think of (that's closer to negative/exploratory testing) — it's specifically about the values immediately next to a defined limit.