What Are Equivalence Partitioning and Boundary Value Analysis?
Equivalence partitioning and boundary value analysis are two closely interlocking black-box test techniques: equivalence partitioning divides the input domain into partitions the system is supposed to treat the same way, and boundary value analysis specifically checks the transitions between those partitions. Together they form probably the most used pairing among the test design techniques.
The idea behind them is economic. Nobody can test an input field with every conceivable value. Nobody has to: if the system demonstrably treats the values 12 and 19 the same way, one of the two suffices as a representative. Things get interesting at the edges. Whether the code contains a less-than or a less-than-or-equal is decided exactly at the boundary value, nowhere else. That is why the notorious off-by-one defects sit at partition boundaries almost every time.
Domain analysis is the name of the next stage of these two techniques at Advanced level: the same basic idea, extended by a named vocabulary of point types (ON, OFF, IN, OUT) and by explicit coverage criteria. The base techniques themselves have always belonged to the Foundation Level.
One clarification up front, because search results for this term like to lead into a different discipline: equivalence classes also exist in mathematics. There, an equivalence relation (reflexive, symmetric, transitive) splits a set into disjoint subsets. Software testing has borrowed the basic idea but runs no proofs. Values count as equivalent if the specification says the system should treat them the same. If you are looking for the mathematical equivalence relation, you are in the wrong place; if you want to know how to secure an input field with nine test cases, you are in the right one.
When Is the Technique a Good Fit?
The technique suggests itself as soon as an input parameter has a clearly defined value range: numeric amounts, quantities, dates, selection lists, string lengths. Business rules with thresholds belong here as well, such as “cancellation free of charge up to 48 hours before arrival” or “early-bird discount from 60 days ahead”.
Its strength lies in input validation and calculation logic whose decisions hang on individual values. Where several separate parameters interact, the technique alone is not enough; there pairwise testing takes over the interplay of the parameters. And when thresholds are embedded in linked business rules, decision table testing is worth a look.
The Procedure in Six Steps
Swipe right or use the arrow keys to see the full graphic.
The sequence is always the same; only partitions, boundaries and values change. The example is a hotel booking form in which the length of stay is valid as a whole number from 1 to 28 nights.
- Identify the input parameters. Which parameters influence the behaviour under test? In the example: the field for the number of nights.
- Determine the value range. Which values does the specification allow? In the example: whole numbers from 1 to 28, both inclusive.
- Form equivalence partitions. Separate valid from invalid partitions. In the example, four partitions: valid (1 to 28), invalid too small, invalid too large, invalid non-integer (letters, decimals, an empty field).
- Determine the boundaries. For each partition, mark the boundary values and record whether the boundary belongs to the partition (closed, as with less-than-or-equal) or not (open, as with less-than). In the example both boundaries are closed: 1 and 28 are valid values.
- Set the points for each boundary. Which point sits where depends on whether the boundary is closed or open. For a closed boundary (the boundary belongs to the partition), the ON point sits on the boundary and the OFF point right next to it outside. For an open boundary it is the other way round: the ON point is the last value inside the partition, the OFF point sits on the boundary. The IN point is a typical value in the middle of the partition, the OUT point a value outside that is not an OFF point. In the example both boundaries are closed: ON points 1 and 28, OFF points 0 and 29, IN point 14, OUT points -3 and 90.
- Derive the test cases. The points of the chosen coverage become the test cases, nine in the example.
A Compact Example
Swipe right or use the arrow keys to see the full graphic.
The hotel booking form from the procedure, played through completely. Length of stay 1 to 28 nights, everything else should trigger an understandable error message:
| Test case | Input | Point type | Expected behaviour |
|---|---|---|---|
| TC-1 | 1 | ON point of the lower boundary | booking possible, 1 night |
| TC-2 | 0 | OFF point of the lower boundary | error message “At least 1 night” |
| TC-3 | 14 | IN point | booking possible, 14 nights |
| TC-4 | -3 | OUT point | error message “At least 1 night” |
| TC-5 | 28 | ON point of the upper boundary | booking possible, 28 nights |
| TC-6 | 29 | OFF point of the upper boundary | error message “No more than 28 nights” |
| TC-7 | 90 | OUT point | error message “No more than 28 nights” |
| TC-8 | ”xx” | representative of the invalid partition “non-integer” | error message “Please enter a whole number” |
| TC-9 | (empty) | representative of the invalid partition “non-integer” | error message “This field is required” |
The inputs “xx” and the empty field fall outside the point scheme. They belong to the invalid partition “non-integer”, and that partition has no ordering, hence no boundary for ON and OFF to refer to. They get tested anyway, as representatives of their equivalence partition. Just not as boundary values.
Suppose TC-2 returns a technical server error in the test run instead of the validation message: the 0 slips through the front-end check and only the database refuses the record. In business terms “just” a wrong error message; technically a hint that the input validation has gaps. A test with a comfortable value from the middle would have shown none of this.
Coverage: Simplified or Reliable
Swipe right or use the arrow keys to see the full graphic.
Two coverage criteria are in common use for domain analysis. Simplified domain coverage demands an ON and an OFF point per boundary; that matches the 2-value scheme of boundary value analysis from the Foundation Level. Reliable domain coverage additionally requires an IN and an OUT point per boundary; it costs a few more test cases and in return also finds defects that don’t sit directly on the boundary.
Both are calculated as the share of tested coverage items out of those required. In the hotel example: the four boundary tests (TC-1, 2, 5, 6) bring simplified coverage to 100 percent; the reliable variant needs the IN and OUT points on top, so TC-3, 4 and 7. The same value may take on several roles: the 14 counts as the IN point for both boundaries at once, which saves a test case. For low-risk fields, the simplified variant is enough; for validations close to money or security, the reliable one pays off.
Strengths and Limits
The technique’s strength: it delivers a defensible coverage with few test cases and aims at the most frequent defect class in input validation, the misplaced boundary. Every input has a nameable role, and the selection can be documented and defended in a review.
The limits are just as clear. The technique stands and falls with the assumption that all values in a partition really are treated the same. Implementations do not always honour that assumption: an inconspicuous value in the middle of the valid partition can still trigger special effects, for instance because it collides with an internally reserved constant. Such hidden special cases need random testing or exploratory testing on top. And with several interacting parameters, the technique checks each boundary cleanly but not the interactions between the parameters.
Related Techniques
Pairwise testing builds directly on equivalence partitioning: per parameter you first form the partitions, then combine their representatives across parameters. Decision table testing takes over when thresholds are part of linked business rules. The page test design techniques gives an overview of all eleven techniques and how to choose between them.