TEST DESIGN
Equivalence Partitioning.
Black-Box A black-box technique that divides input data into groups (partitions) where all values in a group should produce the same result — so testing one representative from each group is sufficient.
What it is
Equivalence Partitioning is the principle that inputs to a system can be divided into classes (partitions) such that any value from within a partition exercises the same code path and produces the same type of result. Because every value in a partition behaves identically, you only need to test one value per partition — you don't need to test every possible input. Typically you identify at least two partitions: a valid partition (inputs the system should accept) and one or more invalid partitions (inputs it should reject). Combining EP with Boundary Value Analysis gives you full coverage: EP selects a representative middle-of-partition value; BVA checks the edges where boundary defects hide.
When to use it
When to use
- Any field with a large input space where testing every value is impossible (e.g. integer fields, text fields)
- Fields with clearly defined valid and invalid input categories (age: valid 18–65 / invalid <18 or >65)
- Fields with multiple distinct valid states (status: 'active' | 'inactive' | 'pending' — three valid partitions)
- As the first step in test design before applying BVA to the boundaries of each valid partition
- When you need to reduce a large test suite without losing meaningful coverage
When NOT to use
- When the partitions are not well-defined in the specification — unclear specs require exploratory testing first
- When interaction between multiple fields matters — use Pairwise Testing to cover combinations
- As a substitute for BVA on range-constrained fields — EP identifies the partitions but BVA is needed to test their edges
How it works
Identify all distinct partitions for an input. For each partition, pick one representative value. Mark each partition as valid (system should accept) or invalid (system should reject). Test each representative and confirm: valid reps are accepted, invalid reps are rejected with the correct error. The worked example uses an age field that accepts 18–65.
Registration form — age field accepts integers 18–65
| Partition | Representative value | Type | Expected result | Result |
|---|---|---|---|---|
| Below minimum (< 18) | 10 | Invalid | Rejected — below minimum age | Reject |
| Valid range (18–65) | 35 | Valid | Accepted | Accept |
| Above maximum (> 65) | 80 | Invalid | Rejected — above maximum age | Reject |
| Non-integer input | 'abc' | Invalid | Rejected — not a number | Reject |
| Negative number | −5 | Invalid | Rejected — below minimum age | Reject |
⚠ EP alone uses 5 tests to represent an infinite input space. Add BVA on the valid partition's edges (17, 18, 19, 64, 65, 66) for full coverage.
Step by step
List all inputs for the function under test
Start with a single field or parameter. List every stated constraint: type (integer, string, date), range (min/max), format (email, phone), and enumerated valid values.
Identify the valid partition(s)
Define the set of values the system should accept. If the field has a range (18–65), the valid partition is all integers in [18, 65]. If it has an enumeration ('red', 'green', 'blue'), each value is its own valid partition.
Identify all invalid partitions
Work outward from the valid partition: values below minimum, values above maximum, wrong type (string in a number field), empty/null, out-of-enum values. Each distinct failure mode is a separate invalid partition — don't collapse them into one.
Pick one representative per partition
The representative should be a typical, clearly-inside-the-partition value — not a boundary value. For the valid range 18–65, pick 35. For the 'below minimum' invalid partition, pick 10 (not 17 — that's a boundary, covered by BVA).
Define the expected result for each representative
Valid reps: accepted, processing continues. Invalid reps: rejected with a specific error message targeting the correct field. Write down the exact expected message or API error code before testing.
Execute and confirm
Enter each representative and verify the actual result matches the expected result. Any accepted invalid value or rejected valid value is a defect. Then apply BVA to the boundaries of the valid partition for complete coverage.
Pitfalls & what it misses
Treating multiple failure modes as a single invalid partition
A value below minimum and a non-numeric value are two different invalid partitions — they fail for different reasons and may trigger different code paths and error messages. Merging them into 'any invalid' misses defects in the error-handling logic for each mode.
Skipping EP for enumerated fields
Dropdown and radio-button fields look trivially simple, but their EP partitions (each valid enum value + at least one invalid value) must all be tested — especially the invalid case, since the client often prevents it but the API doesn't.
Confusing a representative with a boundary value
The value 17 for an age field minimum of 18 is a boundary value (min−1), not an EP representative for the invalid partition. Using boundary values as EP representatives conflates two distinct techniques and can produce misleading coverage counts.
EP doesn't cover ordering or sequencing defects
EP tells you nothing about whether the system behaves correctly when valid inputs arrive in a particular order, or when the same valid input is submitted twice. Combine EP with state-transition testing for stateful workflows.
Paired utility
// Related resources