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.
1 The Hook
A Wellington startup builds an online form for a Waka Kotahi vehicle-licensing service. The age field accepts a driver's age, valid from 16 to 99. A junior tester, keen and thorough, decides to be exhaustive: they enter 16, then 17, then 18, all the way up to 99, then a pile of invalid ages too. Eighty-odd test cases. It takes the best part of a morning.
The next sprint, the valid range changes to 15 to 100. Every one of those eighty test cases has to be reviewed and reworked. Meanwhile, an actual defect slips through: the form happily accepts the text "twenty" because nobody thought to test a non-numeric input — they were too busy typing numbers one at a time. All that effort, and the one partition that mattered went untested.
The waste here is not bad luck. It is the absence of a technique. Testing 16, 17, and 18 tells you nothing that testing just 16 doesn't — the system treats them identically. The effort should have gone into finding the groups that behave differently, not hammering values inside one group that behaves the same.
2 The Rule
If two inputs are processed the same way by the system, testing both is wasted effort — group inputs into partitions that behave identically, then test exactly one representative value from each partition, valid and invalid alike.
3 The Analogy
Sorting the recycling into the kerbside bins.
You do not inspect every single bottle, can, and carton in your house individually. You sort them into groups — glass in one bin, paper and card in another, soft plastics that the supermarket takes back, and rubbish that goes to landfill. Everything within a group is handled the same way, so you only need to know the rule for the group, not for each item. An empty milk bottle and an empty juice bottle go to the same place; checking both is pointless.
Equivalence partitioning is sorting your test inputs into bins. Each bin is a set of values the system treats the same way. You test one item from each bin — and the items that matter most are often the ones that don't fit any of the obvious bins, the odd thing that should go to landfill but someone tries to recycle.
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.
4 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
A NZ council rates-payment portal has a property valuation field. The spec: it accepts a dollar amount from $1,000 to $50,000,000 (inclusive), whole dollars only. Below $1,000 or above $50,000,000 is rejected. Non-numeric input is rejected. List every equivalence partition (valid and invalid) and give one representative value for each.
Show model answer
There are four partitions; a strong answer names all four and gives a representative inside each. 1. Below minimum (Invalid) — anything under $1,000, e.g. 500. Should be rejected. 2. Valid range (Valid) — $1,000 to $50,000,000 inclusive, e.g. 750000 (a typical NZ house valuation). Should be accepted. 3. Above maximum (Invalid) — anything over $50,000,000, e.g. 60000000. Should be rejected. 4. Non-numeric (Invalid) — letters or symbols, e.g. "half a million". Should be rejected. Note: testing $1,000 vs $1,001 is boundary value analysis, not EP. EP only asks you to pick ONE representative per partition — a middle value like 750000 is fine. The non-numeric partition is the one testers most often forget.
A tester partitioned a KiwiSaver contribution-rate field (accepts whole percentages 3 to 10). Their partition set below is flawed: partitions overlap, one is missing, and they test several values from the same partition. Rewrite it into a clean set where each value belongs to exactly one partition and every partition is covered once.
Partition A: 3 to 10 (test 4, 5, 6, 7) — valid
Partition B: 8 to 12 (test 9) — valid
Partition C: 0 to 3 (test 2) — invalid
Rewrite as a clean, non-overlapping partition set:
Show model answer
Clean partition set: Partition 1: below 3 (e.g. 2) — Invalid — one representative is enough. Partition 2: 3 to 10 (e.g. 6) — Valid — ONE representative, not four. Partition 3: above 10 (e.g. 11) — Invalid — one representative. What was wrong with the original: - Overlap: Partition A (3–10) and Partition B (8–12) both contain 8, 9, 10. A value must belong to exactly one partition. - Wasted effort: Partition A tested four values (4, 5, 6, 7) that are all in the same partition — one is sufficient under EP. - Boundary error: Partition C "0 to 3" includes 3, which is actually valid; the invalid-below partition should be "below 3". - Missing partition: nothing covered values above the valid range, so "above 10" was never tested.
Design a complete equivalence-partition set for a field that accepts a New Zealand IRD number. An IRD number is 8 or 9 digits with a modulo-11 checksum. Cover valid and invalid cases. For each partition give a name, valid/invalid, and one representative value.
Show model answer
A strong IRD-number partition set: 1. Valid 8-digit IRD, correct checksum (Valid) — e.g. a known-good 8-digit number. 2. Valid 9-digit IRD, correct checksum (Valid) — e.g. a known-good 9-digit number. 3. Correct length but failing checksum (Invalid) — 8 or 9 digits that don't pass modulo-11. 4. Too few digits, under 8 (Invalid) — e.g. 1234567. 5. Too many digits, over 9 (Invalid) — e.g. 1234567890. 6. Non-numeric characters (Invalid) — e.g. "12-345-678" or "ABC". Bonus partitions a senior would add: empty/blank field, and all-zeros. Note the two valid partitions: you do NOT test every valid IRD number — one correct 8-digit and one correct 9-digit covers the valid space. The checksum-fail partition is what separates a real EP design from "8 or 9 digits, accept".
5 Self-Check
Click each question to reveal the answer.
Q1: Why is it wasteful to test 16, 17, and 18 for an age field valid from 16 to 99?
All three sit in the same valid partition — the system processes them identically, so they give identical information. EP says test one representative of the partition; the others add no coverage. (Testing the edge value 16 itself is boundary value analysis, a separate technique.)
Q2: Which partition do testers most often forget, and why does it matter?
The invalid partitions — especially non-numeric or unexpected-type input. The specification tells you what is valid; you must infer what is not. Invalid partitions are where graceful-rejection bugs (crashes, accepting "twenty" as an age) hide.
Q3: What does it mean for partitions to "overlap", and why is that a defect in your test design?
Overlap means one value belongs to more than one partition (e.g. ranges 3–10 and 8–12 both contain 9). Every value should map to exactly one partition. Overlap signals the partitions are wrongly defined and you may double-test some values while missing others entirely.
Q4: Does equivalence partitioning apply only to numeric ranges?
No. EP applies to any input with distinct groups: strings, dates, dropdown options, file types, user roles, phone-number formats. Anything where some values are processed the same and others differently can be partitioned.
Q5: How do equivalence partitioning and boundary value analysis fit together?
EP defines the partitions; BVA tests the edges between them. EP gives you one mid-range value per partition, BVA adds the values at and just beyond each boundary. They are designed to be used together, not as alternatives.
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 | |