Equivalence Partitioning to Reduce Redundancy

What Equivalence Partitioning Is (and Why It Helps)

Equivalence Partitioning (EP) is a test design technique where you group possible inputs (or conditions) into equivalence classes that are expected to behave the same way. Instead of testing every single value, you test one or a few representative values from each class.

The goal is to reduce redundant tests while keeping meaningful coverage: if many inputs should be treated identically by the system, testing all of them rarely adds new information.

Valid vs. Invalid Partitions

Partitions are commonly split into:

• Valid partitions: inputs/conditions the system should accept and process.
• Invalid partitions: inputs/conditions the system should reject or handle with an error message, validation, or fallback behavior.

Each partition should be defined so that any value inside it is expected to produce the same type of outcome (accepted, rejected, same processing rule, same UI state, same downstream behavior).

How to Define Partitions from Rules

To create equivalence classes, start from the rule that governs the field or behavior. Then translate the rule into partitions based on the type of constraint.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

1) Formats (pattern-based rules)

Use format partitions when input must match a pattern (for example, email, phone number, postal code).

• Valid: matches the required pattern.
• Invalid: does not match the pattern (and you can further split into common failure types if they are handled differently).

2) Ranges (numeric or date limits)

Use range partitions when input must fall within a minimum/maximum (for example, age 18–65, quantity 1–99, date not in the past).

• Valid: within the allowed range.
• Invalid: below the minimum.
• Invalid: above the maximum.

If the system treats different out-of-range values differently (for example, “too young” vs “too old” messages), keep them as separate partitions.

3) Categories (enumerations and dropdowns)

Use category partitions when the system offers a fixed set of options (for example, dropdown values, radio buttons, plan types).

• Valid: each allowed option can be a partition if it triggers different behavior.
• Invalid: missing selection (if required), or an unsupported value (relevant for API/back-end tests).

If multiple options lead to the same behavior, group them into one partition.

4) States (system or user status)

Use state partitions when behavior depends on a condition like authentication, account status, feature flags, or workflow stage.

• Valid states: states where the action is allowed.
• Invalid states: states where the action is blocked, redirected, or requires additional steps.

Example states: logged out vs logged in, active vs suspended account, cart empty vs cart has items.

Choosing Representative Values

Once partitions are defined, choose a representative value for each. A representative value is a typical example from that class, not an edge case.

• Pick values that are easy to understand and clearly belong to the partition.
• Prefer stable, unambiguous examples (avoid values that might be interpreted differently by locale, browser, or environment).
• If an invalid partition has multiple distinct failure modes with different handling, split it into separate partitions and pick one representative for each.

Note: edge-focused values are handled by boundary-focused techniques; here, the emphasis is on “one per class” to avoid redundancy.

Worked Examples

Example A: Email Field (Format Partitions)

Rule: Email must be in a valid email format and is required.

Define partitions:

• V1 (valid): properly formatted email
• I1 (invalid): missing value (empty)
• I2 (invalid): missing “@”
• I3 (invalid): missing domain part after “@”

Pick representatives:

• V1: alex.taylor@example.com
• I1: (empty)
• I2: alextaylorexample.com
• I3: alex@

Why split invalids? If the UI shows the same generic “Invalid email” for all format errors, you could merge I2 and I3 into one “invalid format” partition. If it shows different messages (or logs different error codes), keep them separate.

Example B: Age Field (Range Partitions)

Rule: Age must be an integer between 18 and 65 inclusive.

Define partitions:

• V1 (valid): integer 18–65
• I1 (invalid): integer < 18
• I2 (invalid): integer > 65
• I3 (invalid): not an integer (letters/decimal)
• I4 (invalid): missing value (if required)

Pick representatives:

• V1: 30
• I1: 16
• I2: 70
• I3: 18.5 (or abc, choose one based on what you want to represent)
• I4: (empty)

Example C: Dropdown Selection (Categories)

Rule: “Country” dropdown is required. Allowed values: USA, Canada, Mexico. Selecting USA shows a “State” field; selecting Canada shows a “Province” field; selecting Mexico shows a “State” field.

Define partitions:

• V1 (valid): USA selected (triggers State field)
• V2 (valid): Canada selected (triggers Province field)
• V3 (valid): Mexico selected (triggers State field)
• I1 (invalid): no selection (required field not chosen)

Pick representatives:

• V1: USA
• V2: Canada
• V3: Mexico
• I1: (leave unselected)

Optional optimization: If USA and Mexico truly behave identically (same label, same validation, same downstream mapping), you could group them into one partition “countries that require State.” If they differ in tax rules, shipping, formatting, or backend codes, keep them separate.

Worksheet: From Rules to Minimal Test Cases

Use this worksheet to systematically apply equivalence partitioning and then map partitions into a minimal set of test cases.

Step 1: List the Rules

Write the rules as short, testable statements.

• Email: required; must be valid format
• Age: required; integer 18–65 inclusive
• Country: required; must be one of USA/Canada/Mexico; drives State/Province field visibility

Step 2: Define Partitions (Valid and Invalid)

Create partitions per field/condition. Keep them distinct only when you expect different behavior.

EMAIL partitions:  V1 valid format | I1 empty | I2 invalid format (or split into types)
AGE partitions:    V1 18–65 integer | I1 <18 | I2 >65 | I3 non-integer | I4 empty
COUNTRY partitions: V1 USA | V2 Canada | V3 Mexico | I1 unselected

Step 3: Pick Representative Values

Choose one representative per partition.

EMAIL reps:   V1 alex.taylor@example.com | I1 empty | I2 alextaylorexample.com
AGE reps:     V1 30 | I1 16 | I2 70 | I3 18.5 | I4 empty
COUNTRY reps: V1 USA | V2 Canada | V3 Mexico | I1 unselected

Step 4: Map Partitions into a Minimal Set of Test Cases

Now combine representatives to cover every partition at least once, while keeping the number of test cases small. A practical approach is:

• Create one baseline “all valid” test case.
• For each invalid partition, create a test case where only that one thing is invalid and everything else is valid. This makes failures easy to diagnose.
• For valid category partitions that drive different behavior (like Country), add separate valid tests if the behavior differs.

Baseline valid test case:

TC1 (All valid): Email=alex.taylor@example.com, Age=30, Country=USA
Expected: form accepted; State field visible (USA behavior)

Cover remaining valid country behaviors (because UI changes):

TC2 (Valid Canada): Email=alex.taylor@example.com, Age=30, Country=Canada
Expected: form accepted; Province field visible

TC3 (Valid Mexico): Email=alex.taylor@example.com, Age=30, Country=Mexico
Expected: form accepted; State field visible

Cover email invalid partitions (one invalid at a time):

TC4 (Email empty): Email=empty, Age=30, Country=USA
Expected: validation error for Email; submission blocked

TC5 (Email invalid format): Email=alextaylorexample.com, Age=30, Country=USA
Expected: validation error for Email; submission blocked

Cover age invalid partitions:

TC6 (Age too low): Email=alex.taylor@example.com, Age=16, Country=USA
Expected: validation error for Age; submission blocked

TC7 (Age too high): Email=alex.taylor@example.com, Age=70, Country=USA
Expected: validation error for Age; submission blocked

TC8 (Age non-integer): Email=alex.taylor@example.com, Age=18.5, Country=USA
Expected: validation error for Age; submission blocked

TC9 (Age empty): Email=alex.taylor@example.com, Age=empty, Country=USA
Expected: validation error for Age; submission blocked

Cover country invalid partition:

TC10 (Country unselected): Email=alex.taylor@example.com, Age=30, Country=unselected
Expected: validation error for Country; submission blocked

This set is minimal in the sense that each equivalence class is covered at least once, and tests are not duplicated with multiple values from the same class. If you later discover that different invalid formats produce different messages or backend error codes, split the partition and add one more representative test per new partition.