Equivalence Partitioning
Stop testing every value one by one. Learn how to group inputs into buckets where every member behaves the same way — then test one representative from each bucket.
1 The Hook — Why This Matters
A Christchurch accounting firm launched a new GST return portal. Their tester manually entered fifty random invoice amounts — all passed. On launch day, a contractor entered −$500.00 for a credit note. The system accepted it, calculated negative GST, and fed invalid data straight to Inland Revenue. Three days of manual reconciliation followed, along with an awkward phone call to the IRD help desk.
The tester had tested the "happy path" exhaustively but never thought about groups of bad input. One missing invalid partition — negative numbers — caused real financial pain. Equivalence partitioning would have caught this in five minutes.
2 The Rule — The One-Sentence Version
Divide every input into groups that should behave the same way. Test one representative from each group — never more, never less.
That is the entire technique. Every value in a partition is assumed to be processed identically. If $50.00 works, $500.00 probably works too. If −$1.00 fails, −$100.00 will fail for the same reason. You don't need to prove it fifty times. You prove it once per bucket.
3 The Analogy — Think Of It Like...
Sorting kiwifruit at a Te Puke packing house.
You don't inspect every single fruit for bruises. You create three buckets: export grade, local market, and reject. You pick one fruit from each bucket. If the export bucket is good, they're all good. If the reject bucket is rotten, the whole bucket is rotten. EP is your sorting table for software inputs: valid bucket, too-small bucket, too-big bucket, wrong-type bucket. Test one from each and move on.
4 Watch Me Do It — Step by Step
Here is a real NZ example you can apply to any form you test tomorrow. Follow these six steps every time.
Scenario: A Christchurch car rental site has a "Driver age" field. The business rule is: drivers must be aged 21 to 75 inclusive. Under 21 is rejected. Over 75 is rejected. Non-numeric input is rejected. Empty input is rejected.
- Identify the input domain Any text entered into the "Driver age" field. This includes numbers, letters, symbols, spaces, and nothing at all.
-
Determine equivalence partitions
Separate the domain into groups with identical expected behaviour:
- Valid: 21 – 75 (accepted, normal rental)
- Invalid (too young): < 21 (rejected)
- Invalid (too old): > 75 (rejected)
- Invalid (wrong type): non-numeric (rejected)
- Invalid (empty): blank (rejected)
- Ensure partitions are mutually exclusive A value cannot sit in two partitions at once. "18" is only in "too young". "80" is only in "too old". "abc" is only in "wrong type". No overlap means no confusion.
-
Select representative test values
Pick one value from the middle of each partition:
- Valid: 30
- Too young: 18
- Too old: 80
- Wrong type: "twenty-one"
- Empty: ""
- Design test cases with expected results Document what the system should do for each representative. See the table below.
- Execute and analyse Run the five tests. If any fail, investigate whether the partition assumption was wrong and adjust your groups.
| Partition | Representative value | Expected result |
|---|---|---|
| Valid (21 – 75) | 30 | Accepted |
| Invalid (too young) | 18 | Rejected with error |
| Invalid (too old) | 80 | Rejected with error |
| Invalid (wrong type) | "twenty-one" | Rejected with error |
| Invalid (empty) | "" | Rejected with error |
5 The Decision Tool — When to Use It
✅ Use equivalence partitioning when...
- You have clear input ranges, limits, or categories
- You need to reduce infinite possibilities to a finite test set
- You're testing form fields with defined validation rules
- You are under time pressure and need minimum essential coverage
- The specification defines what is valid and what is not
❌ Don't use it when...
- The input is free-text with no defined groupings
- Behaviour varies inside what looks like one partition
- Multiple fields interact in complex ways (use decision tables)
- The field has no invalid state (e.g., a boolean toggle)
- You need to test the exact edges of a range (use BVA instead)
Before you apply EP, ask:
- Do you understand the business rules that define valid partitions?
- Can you clearly articulate why two values belong in the same partition?
- Have you checked the specification for any edge cases that split a partition?
6 Common Mistakes — Don't Do This
🚫 Skipping invalid partitions
I used to think: If the valid path works, I've done my job.
Actually: Invalid partitions find the most painful bugs. Negative GST amounts, SQL injection via "wrong type" partitions, and crashes on empty fields are almost always found by invalid tests. Never skip them. The happy path is the least likely place for defects.
🚫 Combining two invalid values in one test
I used to think: I'll save time by testing empty AND non-numeric at the same time.
Actually: When a combined test fails, you cannot tell which rule broke. Did the empty check catch it first, or the numeric check? Test one invalid per case. Isolation gives you precise diagnostic information and helps developers fix the right line of code.
🚫 Assuming homogeneity without evidence
I used to think: All mobile phone numbers are one partition because they're all "valid phone numbers."
Actually: In New Zealand, 021, 022, and 027 prefixes route through different carriers. Some systems accept 021 but reject 028. If the spec or evidence suggests internal variation, split the partition. One partition means one expected behaviour.
When EP fails
Wrong partition boundaries allow invalid values to slip through or valid values to be rejected. This happens when the business rules are misunderstood or when the specification is ambiguous. Always validate your partitions against real examples and the specification before designing tests.
7 Now You Try — Online Grant Application
Scenario: You are testing an online form for a New Zealand regional business grant. The "Number of full-time employees" field accepts whole numbers from 1 to 50 inclusive. Zero, negative numbers, non-numeric text, and empty submissions are all rejected.
Your task: List all equivalence partitions for this field and give one representative value for each partition.
Suggested partitions and representatives:
| Partition | Representative | Expected result |
|---|---|---|
| Valid (1 – 50) | 10 | Accepted |
| Invalid (zero / negative) | 0 | Rejected |
| Invalid (above maximum) | 51 | Rejected |
| Invalid (non-numeric) | "fifty" | Rejected |
| Invalid (empty) | "" | Rejected |
Tip: Five partitions means five test cases. You do not need to test every number from 1 to 50. If you also need to test boundaries (0, 1, 50, 51), that is Boundary Value Analysis — the perfect partner for EP.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. If a field accepts ages 18–65, what is the minimum number of EP test cases?
At minimum three: one valid representative (e.g., 30), one invalid below (e.g., 15), and one invalid above (e.g., 70). In practice, you should also add separate partitions for non-numeric input and empty fields, giving you five test cases total.
Q2. Can you combine two invalid values in a single test case?
No. Test each invalid partition in isolation. If you submit an empty, non-numeric value and the test fails, you cannot tell whether the empty check triggered or the numeric check triggered. Isolated invalid tests give precise, actionable failure information.
Q3. Is "empty string" the same partition as "non-numeric input"?
Usually no. Empty often triggers a "required field" error, while non-numeric triggers a "format" or "must be a number" error. Different expected behaviour means different partitions. Always split them unless the specification explicitly states they produce the identical error message and handling.
9 Interview Prep — Know These Cold
These are questions Kiwi employers actually ask junior testers. Have an answer ready.
Q1. What is equivalence partitioning?
Equivalence partitioning is a black-box test design technique that divides input data into groups — called partitions or equivalence classes — where every value in a group is expected to be processed identically. We select one representative value from each partition and design a test case around it. This reduces an infinite or very large input space down to a small, manageable number of tests while still maintaining coverage.
Q2. How many test cases would you write for a password field with length 8–20 characters?
Using EP alone, I would write four test cases: one valid length (e.g., 12 characters), one too short (e.g., 5), one too long (e.g., 25), and one non-numeric/empty if the field requires it. In practice, I would combine this with Boundary Value Analysis to also test exactly 7, 8, 20, and 21 characters, because off-by-one errors are common at boundaries.
Q3. Why do we test invalid partitions separately?
Because combining two invalid values in one test case — for example, submitting a negative number that is also non-numeric — makes diagnosis impossible when the test fails. The developer cannot tell which validation rule fired first. Isolated invalid tests produce clear, unambiguous failure signals that speed up debugging.
Q4. Can EP be used for non-numeric inputs?
Absolutely. Any input with defined categories can be partitioned: dropdown options, file types, user roles, email domains, or New Zealand phone number prefixes such as 021, 022, and 027. If the system is expected to treat all members of a category the same way, EP applies.
10 Link to Reference
Want the full theory, ISTQB syllabus mapping, and advanced application with domain analysis?
→ Equivalence Partitioning — Full Library Reference
Includes the formal ISTQB definition, extended examples with NZ IRD numbers, and how EP pairs with decision tables for multi-field logic.
11 Next Step
You now know how to divide inputs into buckets. The next skill is testing the edges of those buckets — because that is where developers make off-by-one errors.