Equivalence Partitioning
Imagine RecipeBox's "Prep Time (minutes)" field accepts any whole number from 1 to 180. If you wanted to be exhaustive, you could type in every single number from -1000 to 1000 and check the result for each one — but that would take days, and it would mostly be a waste of time, because 45 minutes and 46 minutes are going to behave identically. Equivalence Partitioning (EP) is the technique that formalizes this shortcut: you divide the total range of possible input data into groups — called equivalence classes or partitions — where the application is expected to treat every value in a group the same way. Once you've defined the groups correctly, you only need to test one representative value from each group, because if that one value passes, the assumption is the rest of the group will behave the same, and if it fails, you've found the bug without needing to test the other 179 numbers around it.
What Is Equivalence Partitioning?
Equivalence Partitioning is a black-box test case design technique — you don't need to see or understand RecipeBox's source code to use it, only its documented (or observed) input rules. The core idea has two steps:
- Identify the partitions. Look at every input field and split its possible values into groups that should be handled identically — usually at least one "valid" group and one or more "invalid" groups.
- Pick one representative value per partition. Any value from inside a partition is assumed to be as good as any other value from that same partition, so testing more than one per partition adds cost without adding confidence.
This is different from testing every possible value (which is usually impossible in practice) and different from testing randomly (which gives you no guarantee you've covered the important categories of behavior).
Why It Works: The Economics of Testing
No test team has time to try every possible input. For a numeric field alone, "every possible value" could mean millions of integers, plus decimals, plus text, plus special characters, plus emoji. EP gives you a defensible, repeatable way to say "we covered the important categories of input" without claiming you tried every value — because for well-behaved software, you didn't need to. The technique also forces you to think about the input rules precisely: to partition a field correctly you have to first nail down what the valid range actually is, which alone catches ambiguous or undocumented requirements before you even run a test.
Worked Example: RecipeBox's Prep Time Field
The "Add/Edit Recipe" screen in RecipeBox has a prepMinutes field. The requirement
says: "Prep time must be a whole number of minutes, from 1 to 180." That single sentence
actually implies four distinct partitions:
| Partition | Description | Representative Test Value | Expected Result |
|---|---|---|---|
| Invalid — too low | Any value at or below 0 | 0 (or -5) | Rejected; validation message like "Prep time must be at least 1 minute" |
| Valid | Whole numbers from 1 to 180 | 45 | Accepted; recipe saves successfully with prepMinutes = 45 |
| Invalid — too high | Any value above 180 | 500 | Rejected; validation message like "Prep time can't exceed 180 minutes" |
| Invalid — non-numeric | Letters, symbols, or blank | "abc", empty field | Rejected; field-level error, form does not submit |
Notice that four test values (one per row) give you meaningful coverage of the entire field, instead
of the thousands of values you'd need to check exhaustively. If 45 passes, you don't
also need to try 46, 90, and 150 — they're all in the same
"valid" partition and are assumed to behave the same way, because they all take the same code path
through the application's validation logic.
How Many Test Cases Do You Actually Need?
A common beginner mistake is testing only the "happy path" — just the valid partition — and calling it done. A trained tester always asks: "what are the invalid partitions, and does the app reject them the way it's supposed to?" For a single field like Prep Time, that's usually 3-4 partitions total. For a field with more structure, you'll have more partitions — for example, RecipeBox's "Category" field (a fixed dropdown of Breakfast / Lunch / Dinner / Dessert / Snack) has one partition per valid category, plus an "invalid category" partition for anything sent outside that list (which matters more for API testing than UI testing, since a dropdown normally prevents typing garbage in directly).
Common Mistakes With Equivalence Partitioning
- Only testing the valid partition. The invalid partitions are usually where real bugs hide — apps are built and tested around the happy path, so validation logic for bad input is often an afterthought.
- Drawing partition boundaries in the wrong place. If you're not sure whether 0 belongs to the "valid" or "invalid" group, that's actually a sign you need to go re-read (or ask about) the requirement — don't guess.
- Assuming a partition is uniform when it isn't. If RecipeBox actually treats prep times under 5 minutes differently (say, to flag "no-cook" recipes), that's a fifth partition you missed, not part of the general "valid" one.