Equivalence partitioning divides input data into classes within which the system should behave the same way. Instead of checking dozens of similar values, QA selects one or two representatives from each meaningful class.
The basic idea
If the system handles an entire range identically, testing every value adds little. Identify classes instead: valid, invalid, empty, oversized, prohibited formats, and so on.
A simple example
Suppose an Age field accepts values from 18 through 60 inclusive. At least three classes exist: below 18, 18–60, and above 60. Choose a representative value from each class rather than trying every number.
Applying it in practice
- →First understand validation rules and the business meaning of the field or parameter.
- →Identify classes with different expected behavior.
- →Select one value from each class and consider boundaries separately.
- →Check valid values alongside empty, wrong-type, prohibited, and logically conflicting inputs.
Common mistakes
- →Defining classes mechanically without understanding business logic.
- →Forgetting that equivalence classes do not replace boundary value analysis.
- →Assuming values are equivalent when the system handles them differently.
- →Using only valid classes and ignoring negative inputs.
Equivalence partitioning is particularly useful for forms, API parameters, filters, ranges, statuses, and any input where exhaustive testing is impractical or pointless. Its strength is reducing test volume while retaining logical coverage.
Worked example: integer age eligibility
Training rule: an application accepts an integer age from 18 to 65 inclusive. Treat integer values below 18, from 18 through 65, and above 65 as three disjoint partitions for this rule. Pick one representative from each before adding boundary checks.
Partition Representative Expected
Integer below 18 16 Reject: outside eligible age range
Integer from 18 to 65 40 Accept
Integer above 65 70 Reject: outside eligible age rangeThe model assumes values inside each partition are processed similarly. That is a test-design hypothesis, not proof that one value finds every defect. If the business rule introduces a different result for ages 60–65, split the valid partition accordingly. Do not combine different outcomes merely because all inputs have the same data type.
Keep representation errors separate
Define the transport contract as well. In this exercise a JSON field age must be present and contain an integer number; strings, fractions and null are invalid. The following values are not additional representatives of the three integer partitions.
Payload Expected
{} Reject: required field missing
{"age": null} Reject: integer required
{"age": "40"} Reject: integer required
{"age": 40.5} Reject: integer required
{"age": 40} AcceptExercise and answer
Would 25, 40 and 55 cover the three integer partitions? No: all three are in the valid partition. A set such as 16, 40 and 70 covers all three; then add 17, 18, 19, 64, 65 and 66 to investigate boundary-specific behavior. Expected outcomes come from the stated rule, while HTTP status codes and error schemas require a separate API contract.