Equivalence Partitioning vs Boundary Value Analysis
Both techniques answer the same question: you cannot test every input, so which inputs do you test? They answer it differently, and picking the wrong one leaves a class of bugs untouched.
Equivalence partitioning: stop testing the same thing twice
Split the input domain into groups where the system should behave identically, then test one value from each group.
Take a discount field that accepts 0 to 100. Testing 41, 42, and 43 tells you nothing that testing 42 alone did not, because all three land in the same branch of the same condition. The partitions are what matter:
- 0 to 100, the valid range
- below 0, rejected
- above 100, rejected
- non-numeric input, rejected
- empty, rejected
Five cases instead of a hundred and one. The technique works because a bug that affects 42 almost certainly affects 41, and a developer writing that validation wrote one condition covering the whole range.
Where it fails. Partitions only hold if your guess about the internal grouping matches the implementation. If the developer wrote a special branch for zero, your single test at 42 never touches it. Partitioning assumes uniform handling, and uniform handling is exactly what you are testing for.
Free and open sourceCasely writes these cases for youAttach a spec and one file of your team's existing test cases in Claude. Casely copies your columns, names the gaps it found in the spec, and exports a single Excel file your tracker imports in one pass.Read the install docsBoundary value analysis: bugs cluster at the edges
Developers write the condition wrong at the edge more often than in the middle. Greater-than instead of greater-than-or-equal. A loop that stops one iteration early. An array indexed from zero when the spec counted from one.
For the same discount field, BVA tests the values where behaviour changes: -1, 0, 1, 99, 100, 101. Six cases, all of them at the seams.
An age field accepting 18 to 65 gets 17, 18, 19, 64, 65, 66. The classic off-by-one lives at 65 or 66, and the tester who only checked 30 and 70 never sees it.
Where it fails. BVA needs an ordered domain. A field taking one of four payment methods has no boundaries, because "card" is not adjacent to "bank transfer" in any meaningful sense. Applying BVA to booleans, enums, or unordered sets produces nothing. Reach for decision tables there.
How do you combine them without doubling the suite?
Partition first, then push each boundary. The partitions tell you which regions exist. BVA tells you where to sample inside each one.
For a file upload accepting 1KB to 10MB:
| Case | Input | Why |
|---|---|---|
| 1 | 0 bytes | Empty file, below the lower edge |
| 2 | 1KB | Lower boundary, valid |
| 3 | 2MB | Mid-range representative |
| 4 | 10MB | Upper boundary, valid |
| 5 | 10MB + 1 byte | First rejected size |
| 6 | .exe at 2MB | Different partition: type, not size |
Six cases covering two dimensions. The mid-range value earns its place by catching bugs that only appear away from the edges, which happens when a developer special-cases the boundaries and breaks the general path.
When neither one is the right tool
Both techniques take one input at a time. Real bugs often need two conditions to line up: a premium user, in a region without local payment support, during a promotional period.
Combinations like that call for decision tables, which enumerate the rule set rather than the input range. Sequences of states, such as a subscription moving from trial to active to past-due to cancelled, call for state transition testing, because the bug is usually an illegal transition nobody blocked.
A working order for most features: partition the inputs, walk the boundaries, build a decision table where rules interact, and map states where the entity has a lifecycle. Error guessing fills the gaps that no technique reaches, and it improves with every incident you have lived through.
What part is worth automating?
Splitting a range into partitions and listing its boundaries follows fixed rules. It takes an afternoon across a large spec and it produces the same answer every time, which makes it a good fit for tooling.
Deciding that the upload size limit deserves eight cases while the notification preference gets one is a risk call, and that stays with you.