Equivalence Partitioning
Divide the input domain into groups (partitions) where every value in the group should produce the same result. Test one representative value from each partition instead of every possible value.
What it is
Equivalence Partitioning (EP) is based on a simple principle: if two inputs are treated identically by the system, testing both is wasteful — test one and you've tested both. The technique partitions the input space into equivalence classes, then selects one representative value per class.
This isn't just about numeric ranges. EP applies to any input: strings, dates, dropdown options, file types, user roles — anything with a defined set of acceptable and unacceptable values.
ISTQB definition: "An equivalence partition is a set of values that are assumed to be processed in the same way." A test case for one value in a partition is considered sufficient to represent all values in that partition.
How to apply it
- Identify the input variable — what field, parameter, or condition are you testing?
- Define the partitions — what are the distinct groups of values? Usually: valid range(s) + invalid ranges.
- Pick one representative per partition — typically a value in the middle of each range.
- Derive expected results — what should happen for each representative?
- Write the test case — input, expected output, pass/fail criterion.
Worked example
A form field accepts an age value for an insurance application. Valid ages are 18–65. Under 18 and over 65 are rejected.
Real-world NZ Example: Phone Number Validation
If you're testing an NZ-only checkout form, you might partition the "Phone" field like this:
- Mobile: Starts with 021, 022, 027 (Valid)
- Landline: Starts with 03, 04, 07, 09 (Valid)
- Emergency/Service: 111, 0800 (Often Invalid for personal contact)
- International: +64 (Valid if supported)
- Alphabetical: "CALL ME" (Invalid)
| Partition | Range | Representative value | Expected result |
|---|---|---|---|
| Below minimum (invalid) | < 18 | 10 | Rejected |
| Valid range | 18 – 65 | 40 | Accepted |
| Above maximum (invalid) | > 65 | 80 | Rejected |
Three partitions means three test cases (not 99 values tested one by one). This is the power of EP.
Valid and invalid partitions
Most testers focus on valid partitions (inputs the system should accept) and neglect invalid ones. This is a mistake — invalid partitions often reveal the most interesting bugs:
- Does the system reject the input gracefully with a clear error message?
- Does it accept values it shouldn't?
- Does it crash on unexpected input types?
Always test at least one representative from every invalid partition.
Common trap: treating non-numeric input (empty string, letters, special characters) as one partition. They often behave differently — split them into separate partitions and test each.
ISTQB mapping
| Syllabus ref | Topic | Level |
|---|---|---|
| 4.2.1 | Equivalence Partitioning | CTFL Foundation |
| FL-4.2.1 K3 | Apply EP to derive test cases for a given component or system | Foundation LO |
| CTAL-TA 3.2 | Advanced application of EP with domain analysis | Advanced / Senior |
The ISTQB Foundation exam expects you to apply EP (K3 — not just recall it). You must be able to identify partitions from a specification and derive valid test cases.
Common mistakes
- Testing multiple values per partition — once you've verified the representative, additional values add no coverage.
- Forgetting invalid partitions — the spec tells you what's valid; you must infer what isn't.
- Overlapping partitions — each value belongs to exactly one partition. If partitions overlap, redefine them.
- Ignoring data types — null, empty, 0, negative, and non-numeric inputs often each deserve their own partition.
Related techniques
EP is almost always used with Boundary Value Analysis — EP defines the partitions, BVA tests their edges. Use them together.
For fields with multiple interacting conditions, move to Decision Table Testing.
When applying EP to state-dependent behaviour, combine with State Transition Testing.
Practice this technique: Try Junior Practice 09 — Checkbox & radio logic, Junior Practice 07 — Date picker issues.
NZ example — IRD number validation
New Zealand IRD numbers (Inland Revenue Department) are 8 or 9 digits with a modulo-11 checksum. A field accepting IRD numbers has these partitions:
IRD number equivalence partitions
- Valid 8-digit IRD with correct checksum — valid partition
- Valid 9-digit IRD with correct checksum — valid partition
- Correct length but invalid checksum — invalid partition
- Fewer than 8 digits — invalid partition
- More than 9 digits — invalid partition
- Non-numeric characters — invalid partition
EP says: test one representative from each partition. You do not need to test every valid IRD number — one correct 8-digit and one correct 9-digit value covers the valid partitions entirely.
Voucher code field — identify the partitions
A NZ e-commerce site has a discount voucher code field. The spec says: voucher codes are exactly 6–10 alphanumeric characters. Codes shorter than 6 or longer than 10 characters are invalid. Non-alphanumeric characters (spaces, symbols) are also invalid.
Fill in the partition name and one representative value for each row, then identify the fourth partition.
| # | Partition name | One representative value |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 |
What fourth partition exists in this spec? |
|
| # | Partition name | Representative value | Expected result |
|---|---|---|---|
| 1 | Valid | SAVE10 | Accepted |
| 2 | Too short (below minimum) | AB (any < 6 chars) | Rejected |
| 3 | Too long (above maximum) | SUPERSAVE123 (any > 10 chars) | Rejected |
| 4 | Non-alphanumeric / special characters (e.g. "SAVE!!", "MY CODE") | Rejected | |