Learning Objectives
By the end of this lesson you will be able to:
- Identify valid and invalid partitions for real-world input fields
- Document partitions with their representatives and expected behaviors
- Apply EP to multi-condition specifications
The Two Sides of Every Input
Every input field has at least two kinds of equivalence classes: valid (inputs the system should accept and process) and invalid (inputs the system should reject with an appropriate error).
A thorough EP analysis always documents both. Focusing only on valid inputs means you're testing whether the happy path works — but not whether the guard rails hold.
Real-World Example: Password Field
Specification: "Password must be 8–20 characters long and contain at least one digit."
Let's partition:
| Partition | Description | Representative | Expected Behavior |
|---|---|---|---|
| Valid | 8–20 chars, has digit | SecureP4ss |
Accept |
| Invalid: too short | < 8 chars | Short1 |
Reject: too short |
| Invalid: too long | > 20 chars | ThisPasswordIsWayTooLong1 |
Reject: too long |
| Invalid: no digit | 8–20 chars, no digit | NoDigitHere |
Reject: missing digit |
| Invalid: empty | 0 chars | `` | Reject: required field |
That's 5 test cases from a near-infinite input space. Each one tests a different code path.
Multi-Condition Partitions
When a specification has multiple conditions, partitions can overlap or multiply. The password example above has two conditions (length AND digit presence). A professional tester would also consider:
- What if the password is exactly 8 characters and has a digit? (boundary + valid digit)
- What if it's exactly 20 characters and has no digit? (boundary + missing digit)
This is where EP transitions into BVA. For now, the key insight is: each independent condition in the spec can generate its own set of partitions.
Documenting Your Partitions
A good partition table includes:
- Partition name (descriptive)
- The condition it represents
- A specific test value (the representative)
- The expected result
Pro Tip: When writing bug reports, reference the partition name. "Bug occurs in the 'too short password' partition" is immediately actionable — the developer knows exactly what to reproduce.
The "Invalid but Processed" Trap
Sometimes invalid inputs get processed instead of rejected. This is often a more serious bug than a crash — the system accepted bad data into its database or calculations.
When testing invalid partitions, don't just verify that an error message appears. Also verify:
- The data was NOT saved to the database
- The calculation was NOT performed with the invalid input
- The user was given clear feedback about WHY the input was rejected
Key Takeaways
- Every input has valid and invalid partitions — document both
- Multi-condition specs generate multiple independent partition sets
- A partition table (name, condition, representative, expected) is a professional deliverable
- Verify that invalid inputs are truly rejected, not just flagged