Equivalence partitioning

Equivalence partitioning is the reasoning that makes finite testing defensible. The input space for almost any field is far too large to enumerate, so the tester divides it into classes on the argument that every member of a class exercises the same path through the system. If that argument holds, one value from each class carries the same information as a thousand, and the remaining nine hundred and ninety-nine are duplicated effort dressed up as thoroughness.

The technique is only as sound as the partitions, and getting them wrong is the interesting failure mode. Classes must cover the whole space and must not overlap, which sounds procedural until you meet a field where the invalid inputs are not one class but several — too long, wrong character set, correctly formatted but referring to something that does not exist. Each of those follows a different route through the code and produces a different message, so treating them as one group hides the one that is broken.

Partitioning that survives review

• Split the invalid side properly. Most teams identify one valid class and one invalid one, and the invalid class is almost always three or four behaviours wearing a single label.
• Partition on behaviour rather than on appearance. Two inputs that look similar belong in different classes if one triggers a lookup and the other does not.
• Combine with boundary analysis rather than choosing between them: partitions tell you which groups exist, boundaries tell you which values within each group to use.
• Re-derive the partitions when the rules change. A new validation rule silently splits an existing class in two, and the old case set now tests one half twice and the other never.

The method assumes the implementation treats a class uniformly — an assumption the code can violate, which is why partitioning reduces the case count rather than guaranteeing the result.