Equivalence partitioning on a real signup form

A tester spent an afternoon on a signup form. She tried 40 different email addresses: with dots, with plus signs, with two at-signs, with a trailing space. Thorough work.

She never touched the country dropdown, and that is where the bug was. Users in countries with no listed state or province could not submit the form at all.

Forty tests on one field, zero on another. Equivalence partitioning is the technique that stops this from happening.

Short version

• A partition is a group of inputs that the software should treat the same way.
• If one value in the group works, the rest almost certainly work too.
• Test one value from each partition instead of many values from one field.
• The signup form below has 30 partitions and needs 24 test cases, not 65,536.
• Pair it with boundary value analysis to cover the edges between partitions.

---

What equivalence partitioning means

An equivalence partition (also called an equivalence class) is a set of input values that the software should handle in exactly the same way.

Take an age field that accepts 18 to 120. The values 25, 40, and 77 all sit in the same partition: "a valid adult age". The code takes the same path for all three. Testing all three tells you almost nothing more than testing one.

So you pick one value per partition. That is the whole idea.

The technique has two halves that people often forget:

• Valid partitions — groups the system should accept.
• Invalid partitions — groups the system should reject, each for a different reason.

"Too young" and "not a number" are two different invalid partitions, because they produce two different error messages and follow two different code paths.

The form we are testing

Here is the form at https://staging.example.com/signup. Eight fields, with the rules taken from the ticket:

1. Full name — required, 2 to 60 characters
2. Email — required, must be a valid address, must not already exist
3. Password — required, 8 to 64 characters, must contain a number
4. Country — required, dropdown with 195 options
5. Age — required, whole number, 18 to 120
6. Plan — required, one of Free, Pro, Team
7. Promo code — optional, exactly 8 characters if entered
8. Terms checkbox — must be ticked

Testing every combination of every field is impossible. Even if you allowed just four values per field, that is 4 to the power of 8, or 65,536 combinations. At two minutes each that is 45 working days.

Partitioning each field

Go through the fields one at a time and write down the groups. Give each group a name and pick one representative value.

That is 14 valid partitions and 16 invalid ones, 30 in total.

Two of these deserve a note.

Country splits into two valid partitions, not one. Countries with states show an extra dropdown; countries without states do not. Different behaviour means different partitions. This is exactly the split the tester in the opening story missed.

Plan splits into three, because each plan can trigger different behaviour after signup: Free goes straight to the dashboard, Pro and Team go to a payment step. If they all behaved identically, one partition would be enough.

Turning partitions into test cases

Now use two simple rules.

Rule 1: combine valid partitions freely. Valid values do not interfere with each other, so one test case can cover several valid partitions at once.

Rule 2: test one invalid partition at a time. If you submit a form with three invalid fields and it fails, you do not know which rule caught it. Worse, the first failing check may hide the other two — a problem called error masking.

Applying rule 1, the 14 valid partitions collapse into 3 test cases:

1. Aisha Khan / [email protected] / Test1234 / United States / 30 / Free / promo empty / ticked
2. O'Brien-Smith / [email protected] / a 64-character password / Singapore / 18 / Pro / SUMMER26 / ticked
3. Li Wei / [email protected] / Passw0rd / United States / 120 / Team / SPRING25 (expired) / ticked

Applying rule 2, each of the 16 invalid partitions gets its own test case. Every other field holds a known-good value, so only one thing can go wrong.

Total: 3 + 16 = 19 test cases for the partitions. Add five boundary cases for age and password length (17, 18, 120, 121, and a 7-character password) and you land at 24 test cases.

Twenty-four instead of 65,536. And unlike the 40 email tests, this set touches every field.

What partitioning does not cover

Equivalence partitioning assumes every value inside a partition behaves the same. That assumption breaks in three places, so cover them separately.

The edges. The values 18 and 17 sit in different partitions, but they are one apart. Use boundary value analysis for those.

Combinations that interact. "Team plan" plus "promo code" might behave differently from "Free plan" plus "promo code" if the code only applies to paid plans. Rules that depend on more than one field belong in a decision table.

Hostile input. Emoji, right-to-left text, 10,000-character strings, and strings that look like SQL are their own partitions. Add them once per text field rather than everywhere.

When one of these does break, capture the evidence at the moment it happens. A partition bug usually shows up as a failed request rather than a visible error, so a browser-based reporter such as Crosscheck that grabs the console output and the network call along with the screenshot removes the guesswork later.

Where partitioning goes wrong

Splitting too finely. If you create a partition for every possible email format, you are back to 40 email tests. Ask yourself: does the code take a different path for this value? If not, it belongs in the existing partition.

Splitting too coarsely. One "invalid email" partition is not enough when the form shows three different error messages. Different message, different partition.

Forgetting the empty case. Optional fields need a "left empty" partition. It is the most common state in production and one of the least tested.

Guessing partitions from the interface only. The dropdown may show 195 countries, but the API may accept any two-letter code. Send XX directly to POST /api/signup and see what happens.

A five-step routine you can reuse

1. List every field and its rules.
2. For each field, write the valid groups. Ask what changes the behaviour, not what changes the value.
3. Write the invalid groups. One per error message or rejection reason.
4. Pick one concrete value per partition and write it down.
5. Build the case list: valid partitions combined, invalid partitions one at a time.

Keep the partition table next to the test cases. When the rules change, you update the table first, and the cases follow.

Frequently asked questions

How is equivalence partitioning different from boundary value analysis?

Partitioning picks one value from the middle of each group. Boundary analysis picks values at the edges where groups meet. They cover different bugs, so use both on the same field.

Can I combine two invalid values in one test case?

Avoid it. If the form rejects the submission you cannot tell which rule fired, and the first failing check often stops the others from running.

How many values should I take from each partition?

One is the standard. Take a second only if you have a specific reason to doubt the group, such as a field where the code has separate handling for uppercase and lowercase.

Does this work for dropdowns and radio buttons?

Yes, if the options cause different behaviour. Group options that lead to the same result and test one from each group. If all 195 countries behave identically, they are one partition.

Should I write the partitions down or keep them in my head?

Write them down. The table is the part that survives, and it is what lets someone else run or review the tests when the rules change.