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 TransitNZ 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.
Equivalence partitioning groups all the values a system treats identically, then tests just one representative from each group — replacing dozens of redundant test cases with a small, deliberate set. Use it whenever a field has a defined range of valid and invalid values: numeric amounts, dates, Revenue NZ numbers, user roles, phone formats. The mistake testers most often make is skipping the invalid partitions — the spec tells you what is valid, so you must infer the invalid groups yourself, and those are exactly where graceful-rejection bugs hide.
The dangerous assumption in equivalence partitioning is that the spec's valid range is one partition. In practice, developers often implement sub-ranges with separate code paths — a KiwiSaver contribution field that "accepts 3 to 10 percent" might have distinct branches for employer-minimum (3%), default rates (4–8%), and voluntary-max (9–10%), each written by a different developer. The spec gives you one valid partition; the code gives you three. I've seen this exact pattern produce silent miscalculations in an CoverNZ earnings-replacement calculation — every test passed because all representatives landed in the same branch. Before signing off, ask the dev: "Are there any sub-ranges inside the valid partition that the code handles differently?" That one question has found more defects for me than doubling the test count.
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.
Common Mistake vs What Works
Creating one partition per input field. A form with five fields gets five partition lists, one for each field, where testers pick a handful of values per field and call it done. Partitions are organised by field name, not by how the system actually responds — so "Name: empty" and "Name: 500 characters" end up in the same bucket even if one returns a "required field" error and the other silently truncates.
Define partitions by system behaviour, not by input field. Ask: does the system respond differently to these two values? If a 500-character name triggers a "too long" error but an empty name triggers "field required", those are two separate invalid partitions — each needs its own representative. This question, asked for every pair of candidate values, is the entire technique. Get the partitions right and the test cases write themselves.
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 Industry Reality
- Requirements rarely spell out every partition. A spec might say "accepts an age between 16 and 100" — you have to infer the invalid partitions yourself (under 16, over 100, non-numeric, empty). Senior testers add partitions the spec didn't think to mention, like zero, negative numbers, and decimals.
- Legacy systems often process invalid inputs silently. In NZ government and banking systems built before modern validation became standard, submitting a negative KiwiSaver percentage or a 15-digit Revenue NZ number doesn't always return an error — sometimes it stores the value, breaks downstream calculations, or generates a bad audit record. Finding these gaps is where EP earns its keep.
- Partitions shift mid-sprint. The valid age range changes, a new file type gets supported, Revenue NZ drops its modulo-11 check for API submissions. You won't have 80 test cases to update if you designed by partition — just update the boundary and pick a new representative. This is the maintenance win teams don't appreciate until they've been burned.
- Time pressure collapses EP to "test a happy path and a null". Under deadline, many testers skip invalid partitions entirely. The real discipline is keeping the partition list minimal but complete — three partitions take the same time to execute as one if the test data is well-designed, so there is no good excuse for dropping the invalids.
- Senior testers combine EP with risk weighting. In a high-volume transaction system (e.g. a NZ bank's payment gateway), the non-numeric invalid partition might be worth three test cases — one for letters, one for special characters, one for Unicode — because different parsers handle them differently. Textbook EP says one representative. Experienced testers know when to split a partition further based on implementation risk.
Senior engineer insight
I once tested a Revenue NZ tax-credit portal where the spec said the income field accepted values from $0 to $180,000 — one valid partition. Three months after go-live, a defect was raised: the system was silently applying two different rounding algorithms depending on whether the amount was above or below $48,000 (the threshold for a different tax rate), which the developer had embedded in the code but never mentioned to the team. We’d tested $90,000 as our valid representative and never touched either side of that internal boundary. The lesson wasn’t that EP failed — it was that I stopped at the spec instead of asking the developer whether the valid range had any internal branches. That one question, asked before test design, would have found it on day one.
The most common mistake I see from graduates is treating the valid partition as automatically “done” with a single mid-range value, without ever asking whether the implementation has sub-ranges the spec forgot to mention.
From the field
We were testing a Revenue NZ tax-rate portal where income bands drove different calculations — the $14,000, $48,000, and $70,000 thresholds mapped to four CoverNZ levy classes with separate rounding rules. The team assumed the valid income range was one partition and chose $40,000 as their single representative. Three weeks after go-live, a payroll provider reported that incomes between $48,001 and $70,000 were applying the wrong levy multiplier — a code branch none of us had exercised. When we traced it back, the developer had split the "valid range" into four internal sub-ranges at exactly those thresholds; the spec said nothing about them. We added three more mid-range representatives, found two more silent mismatches above $70,000, and from that point on we made it a standing rule to ask every developer before sign-off: "Does the valid range have sub-ranges the code handles differently?" That one question now sits at the top of our EP checklist for every NZ regulated-calculation field.
5 When to Use It — and When Not To
✓ Use it when
- A field or parameter has a defined range of valid and invalid values — age, dollar amounts, Revenue NZ numbers, dates, phone formats.
- You need to cut a large input space down to a manageable test set without losing coverage — EP's core promise.
- Requirements are written clearly enough to identify distinct groups (the "processed the same way" test).
- You're designing test cases for ISTQB preparation — EP is explicitly examinable at K3 (apply, not just recall).
- The system under test has multiple invalid input categories that each produce different error behaviour (reject vs. truncate vs. crash).
✗ Skip it when
- You need to test the edge between partitions — that's Boundary Value Analysis, which extends EP rather than replacing it.
- The input space has complex interactions between multiple fields — use Decision Table Testing or Pairwise Testing instead.
- You're exploring unknown behaviour in a new system with no spec — start with Exploratory Testing to discover the partitions first.
- The field is free-text with no semantic rules (e.g. a comments box) — there are no meaningful equivalence groups to test.
- You're doing regression testing on already-partitioned inputs — the partition analysis is done; just reuse the existing representatives rather than rederiving them.
Context guide
How the right level of Equivalence Partitioning effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Regulated government system (Revenue NZ, CoverNZ, Benefits NZ, TransitNZ) | Essential | Invalid data reaching a benefit calculation or tax record creates audit failures and downstream corrections that cost far more than the test cases would have. Every invalid partition is a compliance risk in disguise. |
| Banking or financial services (eligibility rules, KiwiSaver, payment thresholds) | Essential | Category-based business logic (contribution bands, fee tiers, credit-score buckets) means the valid range frequently has undocumented internal sub-partitions the spec never mentions. EP forces you to ask the developer before sign-off. |
| Enterprise system with form validation (council portals, eligibility forms, rate-payment workflows) | High | High field count and complex input classification (NZ phone formats, Revenue NZ numbers, address types) make EP the primary tool for keeping the test suite manageable without sacrificing coverage. |
| Agile sprint — mid-cycle feature with defined acceptance criteria | Medium | Sprint velocity pressure tempts teams to test only the happy path. EP gives you the minimum valid-plus-invalid set in under 10 minutes, which fits inside a sprint without negotiation — but only if the acceptance criteria are specific enough to define partition boundaries. |
| Legacy system migration (re-platforming an existing NZ line-of-business application) | Medium | The old system's behaviour becomes the specification — reverse-engineer partitions by observing what the legacy app accepts and rejects. EP is valuable but depends on how well the old behaviour is documented or observable. |
| Small startup — MVP with minimal spec and rapidly changing requirements | Low | When rules change every sprint and there is no formal spec, partition analysis becomes stale before you execute it. Start with exploratory testing to discover what the system actually does, then introduce EP once the input rules stabilise. |
Trade-offs
What you gain and what you give up when you choose Equivalence Partitioning.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Dramatically reduces test count without losing logical coverage — one representative per partition replaces dozens of redundant values. | Misses bugs that live exactly at partition boundaries (off-by-one errors, fence-post mistakes in range checks). | The bug risk is highest at the edges — layer Boundary Value Analysis on top of EP rather than using EP alone. |
| Forces explicit definition of invalid partitions, surfacing missing validation logic that the spec never mentioned. | Requires a reasonably clear spec — without defined rules you're guessing where partition boundaries sit, which makes the analysis unreliable. | Behaviour is unknown or under-specified — start with Exploratory Testing to discover the partitions before you can define them. |
| Partition tables are durable — when a range changes (e.g. TransitNZ updates a fee threshold), you update one boundary and pick a new representative rather than reworking dozens of test cases. | Handles only one input variable at a time — it cannot model interactions between fields (e.g. discount rate combined with minimum order value producing different outcomes). | Multiple fields interact to produce different system behaviour — use Decision Table Testing or Pairwise Testing to model the combinations. |
| Works across all input types — numeric ranges, strings, dates, user roles, file types, NZ phone formats — wherever distinct groups exist. | Gives false confidence on free-text fields — a comments box or a name field with no semantic rules has no meaningful partitions, so applying EP produces nothing useful. | The field is free-text with no enforced rules — switch to exploratory or scenario-based testing. |
| Scales well to regulated NZ systems (Revenue NZ, CoverNZ, Benefits NZ) where invalid data carries compliance risk — EP makes invalid partitions first-class test citizens, not afterthoughts. | Can produce a false sense of completeness if a developer has implemented hidden sub-ranges inside a nominally single valid partition — the spec says one range, the code has three branches. | You suspect undocumented internal branches — ask the developer directly, then split the valid partition further if confirmed. |
6 Best Practices
- Always derive invalid partitions before writing a single test case. Ask: what values are explicitly invalid per the spec, and what values are implicitly invalid (wrong type, empty, null, zero)? List them before you pick representatives.
- Use middle-of-range values as representatives, not values near the boundary. If the valid range is 18–65, use 40, not 18 or 65 — boundary testing is a separate technique (BVA). Picking 18 blurs the two techniques and can mask EP errors.
- Name your partitions before numbering them. "Below minimum", "Valid range", "Above maximum", "Non-numeric" are more durable than "Partition 1/2/3/4". When the spec changes, named partitions are easier to update and review.
- Treat each distinct error behaviour as a separate partition. If an empty string returns "field required" but a letter returns "invalid format", they are two different partitions despite both being "invalid non-numeric input".
- Document the EP table in your test plan, not just the test cases. The partition table is the analysis artefact. Reviewers and future testers need to see why you chose those representatives, not just what they are.
- Pair EP with Boundary Value Analysis on every numeric partition. They are designed to complement each other. EP gives you coverage across the space; BVA stress-tests the fences between partitions. Use both.
- When the spec is ambiguous, ask — then document the answer as a partition boundary. "What happens if the user enters 0?" is a design question, not just a test question. Getting the answer clarifies a partition and prevents a defect.
- In NZ regulated systems (Revenue NZ, CoverNZ, Benefits NZ, TransitNZ), invalid partitions carry compliance risk. A field that accepts an invalid Revenue NZ number isn't just a UX issue — it may create invalid tax records. Treat invalid-partition test failures as high-severity by default.
- Re-examine partitions when the spec changes, not just the test data. If the valid age range shifts from 18–65 to 16–70, the partition structure is the same but the boundaries have moved. Update the partition definition, then pick a new representative — don't just change the value in an existing test case without checking whether the partition itself changed.
7 Common Misconceptions
❌ Myth: Equivalence partitioning means you only need one test case total.
Reality: EP means one representative per partition, not one test case per field. A single field often has four or more partitions (valid range, below minimum, above maximum, non-numeric, empty). The reduction in test count is dramatic compared to testing every value, but you still need a test case for each distinct partition — including every invalid one.
❌ Myth: EP and Boundary Value Analysis are the same thing — just pick values at the edge.
Reality: EP and BVA are related but distinct. EP partitions the input space and picks a representative in the middle of each partition. BVA specifically targets the values at and adjacent to partition boundaries, where off-by-one errors in code are most likely. You apply EP first (identify the partitions), then BVA on top (stress the edges). Picking 18 as your EP representative when the valid range starts at 18 means you're conflating the two techniques — use 40 for EP, then add 17, 18, 65, 66 for BVA.
❌ Myth: EP only applies to numeric input fields.
Reality: EP applies to any input where distinct groups are processed differently. User roles (admin, standard, read-only), file types (PDF, DOCX, XLSX, unsupported), NZ phone number formats (mobile 02x, landline 0[3479], 0800 free-call, international +64), dropdown options, date formats — all of these have equivalence partitions. The technique is about the behaviour of the system in response to an input group, not about the input being numeric.
8 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 Revenue NZ number. An Revenue NZ 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 Revenue NZ-number partition set: 1. Valid 8-digit Revenue NZ, correct checksum (Valid) — e.g. a known-good 8-digit number. 2. Valid 9-digit Revenue NZ, 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 Revenue NZ 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".
Why teams fail here
- They treat the spec's valid range as a single partition without asking whether the code has internal sub-ranges — Revenue NZ tax brackets, CoverNZ levy classes, and council rate categories all have stepped logic inside a nominally single range, and no specification ever lists those internal branches explicitly.
- They identify valid partitions and stop, never deriving the invalid ones — the spec tells you what is accepted, so the invalid partitions require inference, and that inference step is exactly where graceful-rejection bugs are caught or missed.
- They pick boundary values as partition representatives — testing 14,001 instead of a true middle value like 30,000 conflates EP with Boundary Value Analysis and leaves the core of the partition unexercised.
- They collapse all invalid input into one partition — an empty field, a negative dollar amount, a letter, and a value of zero each trigger different code paths and different error messages, which means they are four separate invalid partitions, not one.
Enterprise reality
Large-scale systems where test data generation is a bottleneck
- Partitions are defined once in a shared test data specification owned by the QA team, so every squad drawing on the same system (Revenue NZ, CoverNZ, KiwiSaver platform) uses identical partition definitions rather than each team reinventing them independently.
- Data factories or synthetic data generators produce one representative value per partition on demand — testers declare the partition class they need, and the toolchain creates a compliant value, removing the manual effort of constructing edge-case test data at volume.
- Partition definitions are reviewed by business analysts and domain experts before test design begins, ensuring completeness — in NZ regulated environments this review is part of the test-readiness checklist because a missing invalid partition can mean an untested compliance gap.
- Coverage tooling tracks which partitions have been exercised across the full test suite, not just within a single test plan — overlapping or unexercised partitions surface automatically rather than depending on a manual reviewer to spot them in a test case spreadsheet.
How this has changed
The field moved. Here is how Equivalence Partitioning evolved from its origins to current practice.
Equivalence partitioning documented by Myers alongside BVA. The core insight — that all values in a partition behave identically — reduces infinite input spaces to manageable sets. Foundational academic technique.
ISTQB certifies EP as a standard black-box technique. Tester education improves, but application remains informal in practice — few teams document partitions explicitly. Most partition identification is intuitive rather than systematic.
Domain analysis and model-based testing give EP a more rigorous foundation. Specification-based testing research clarifies how to derive partitions from requirements systematically rather than by intuition.
Property-based testing (QuickCheck, Hypothesis, fast-check) automates the generation of values within each partition. The technique gains a programmatic expression — developers use it without necessarily knowing its name.
AI test generation tools propose equivalence classes from natural language requirements and code analysis. Teams verify the partition coverage rather than derive it. The conceptual foundation remains unchanged; the implementation has been largely automated.
9 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.
Q6: Your team is testing a Benefits NZ benefit-payment portal where applicants enter their weekly income. The valid range is $0 to $2,500 per week; anything above is rejected, and non-numeric input is rejected. A colleague suggests testing $0, $500, $1,000, $1,500, and $2,500 to "cover the range thoroughly". What would you say, and what would a proper EP set look like?
A: Testing five values inside the same valid partition adds no coverage — the system processes all of them identically. EP requires one representative per partition, not multiple values from the same group. A correct set has four partitions: below minimum (invalid, e.g. -1), valid range ($0–$2,500, e.g. $800), above maximum (invalid, e.g. $3,000), and non-numeric (invalid, e.g. "two hundred"). For Benefits NZ systems, the non-numeric and negative partitions are especially important because invalid data silently flowing into benefit calculations can create compliance and audit risk.
Q7: What is the key difference between equivalence partitioning and decision table testing, and how do you decide which to reach for?
A: EP handles a single input variable with distinct groups of values — it reduces how many values you test for each variable. Decision table testing handles combinations of multiple conditions that interact to produce different outcomes. If you are testing what happens when a KiwiSaver member is both under 18 and requests a hardship withdrawal while their balance is below the minimum, that is a multi-condition combination problem for a decision table, not an EP problem. Reach for EP first to partition each individual field, then use a decision table when those fields interact to produce different system behaviour.
Q8: When is equivalence partitioning the wrong technique to reach for, even on a field that clearly has valid and invalid values?
A: EP is the wrong primary technique when the interesting bugs live at the boundary between partitions rather than inside them — that is when you need Boundary Value Analysis. It is also wrong when the field is free-text with no semantic rules (a comments box has no meaningful partitions), when you are exploring unknown behaviour with no spec (use exploratory testing to discover the partitions first), and when inputs interact across fields (a discount percentage combined with a minimum order amount is better modelled in a decision table). EP requires a defined spec; without one, you are guessing where the partition boundaries sit.
Q9: A developer on your team says "We already validate the field client-side in JavaScript, so we only need to test the happy path — invalid inputs never reach the server." What is wrong with this reasoning and how do you respond?
A: Client-side validation can be bypassed trivially — by disabling JavaScript, using browser developer tools, or sending a direct API request. Invalid partitions must be tested at the server or API layer regardless of what the front end blocks. In NZ regulated systems (Revenue NZ submissions, CoverNZ claims, RealMe identity verification), an invalid value that slips past a client-side check and reaches the back end can corrupt records, trigger incorrect calculations, or create audit failures. The invalid partitions of your EP set should always include a direct API-level test to confirm the server enforces the same rules the UI does.
★ Interview Questions
What NZ hiring managers ask about Equivalence Partitioning — and what strong answers look like at each level.
Q: What is equivalence partitioning, and why do we use it instead of testing every possible input value?
Strong answer: Equivalence partitioning divides the input space into groups where every value in a group is expected to behave the same way — so testing one representative from each group is enough. We use it because exhaustive testing is impossible on any real system: an age field with a valid range of 16 to 99 has 84 valid integers alone, plus an infinite set of invalid values. EP lets us replace that with three or four test cases while keeping genuine coverage. The technique also forces you to think explicitly about invalid partitions, which is where many graceful-rejection bugs hide.
Grad / Junior
Q: A KiwiSaver contribution-rate field accepts whole percentages from 3 to 10. Walk me through the equivalence partitions you would define.
Strong answer: There are three non-overlapping partitions: below the minimum (invalid) — anything under 3, representative value 2; the valid range 3 to 10, representative value 6 (a middle value, not a boundary); and above the maximum (invalid) — anything over 10, representative value 11. I would also add a fourth partition for non-numeric input such as a blank or the word "max", because the system's response to a type error is likely different from a numeric out-of-range error. For a KiwiSaver system I would flag the non-numeric and below-minimum partitions as high severity because invalid data flowing into contribution calculations creates downstream compliance risk.
Junior
Q: When would you NOT use equivalence partitioning, even on a field that clearly has valid and invalid values?
Strong answer: I would reach for a different technique in three situations. First, when the important bugs live at the boundaries between partitions rather than in the middle — that is when I add Boundary Value Analysis on top of EP, or lead with BVA. Second, when the field has no semantic rules (a free-text comments box has no meaningful partitions). Third, when inputs across multiple fields interact to produce different behaviour — a discount percentage combined with a minimum order value is better modelled in a decision table, because EP only handles one variable at a time. EP also assumes a clear spec; if I am exploring unknown behaviour in a new system, I would start with exploratory testing to discover the partitions before I can define them.
Senior
Q: A developer tells you "we validate the field client-side in JavaScript, so invalid inputs never reach the server — you only need to test the happy path." How do you respond?
Strong answer: Client-side validation is trivially bypassed by disabling JavaScript, using browser developer tools to modify the DOM, or sending a request directly to the API endpoint. For any NZ regulated system — Revenue NZ submissions, CoverNZ claims, Benefits NZ benefit calculations, RealMe identity flows — an invalid value that slips past the front end and reaches the back end can corrupt records or trigger incorrect calculations. I would always include direct API-level tests for the invalid partitions to confirm the server enforces its own rules independently of the UI. This is also an ISTQB principle: the test object is the system, not just the presentation layer.
Senior
Q: A developer tells you the valid range for a KiwiSaver earnings field is "one partition" — all values behave the same. You suspect there are actually sub-ranges with different code paths. How do you investigate, and what would make you split the valid partition further?
Strong answer: I would ask the developer directly: "Are there any sub-ranges inside the valid partition where the code takes a different branch?" Developers often implement multiple code paths within a nominally single range — for example an CoverNZ earnings-replacement calculation might have separate logic for below the minimum weekly earnings threshold, the standard band, and above the maximum compensation cap, each written by a different developer. If they confirm sub-ranges, I treat each as its own valid partition and pick a representative from each. If they are unsure, I would review the code or run a session of exploratory testing with values at likely breakpoints. This is the single question that has found more partition defects for me than doubling the total test count.
Senior
Q: You are onboarding a cohort of junior testers who keep writing 6–8 test cases per field and missing invalid partitions entirely. How do you teach EP in a way that sticks, and how do you measure whether it has changed their behaviour?
Strong answer: I teach EP as a two-question habit rather than a technique: "How many groups does the system treat differently?" and "What input types are implicitly invalid that the spec did not mention?" Running through a live example — partitioning an Revenue NZ number field together, including the checksum-fail partition that most people miss — lands better than a slide deck. For measurement, I do a brief partition-table review on each tester's next test case design: I count their partitions, check whether every invalid type has its own entry, and confirm representatives are mid-range values rather than boundary values. After two or three reviewed designs, most testers internalise the habit. I also track defect escape rate on fields that were EP-tested versus those that were not, which gives the team a concrete quality signal rather than a process compliance metric.
Lead
◆ What I would do
Professional judgment — when to reach for Equivalence Partitioning, when to skip it, and what to watch for.
The bottom line: Equivalence Partitioning is not a test-reduction technique — it is a thought discipline: before you write a single test case, force yourself to name every group the system treats differently, especially the ones no one asked you to test.
Key takeaway
Your partition list is only as good as the questions you asked before you wrote it — one conversation with the developer about hidden sub-ranges and one hard look at what the spec forgot to call invalid are worth more than doubling your test count.
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 — Revenue NZ number validation
New Zealand Revenue NZ numbers (Revenue NZ) are 8 or 9 digits with a modulo-11 checksum. A field accepting Revenue NZ numbers has these partitions:
Revenue NZ number equivalence partitions
- Valid 8-digit Revenue NZ with correct checksum — valid partition
- Valid 9-digit Revenue NZ 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 Revenue NZ 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 | |