An equivalence class is a particular mathematical object: it is not, as some books would lead us to believe, a group of tests subjects that are "equivalent". To understand what an equivalence class really is we need to first understand the insight that software control, data, and transaction paths can be defined by relations. For example, variable A is less than or equal to variable B; or, process step A depends on process step B. Relations have properties such as transitivity, reflexivity, symmetry, and so forth. A relation which has all three of these properties is called an equivalence relation and it defines an equivalence class. The set of elements over which the relation ranges can be partitioned into disjoint subsets (the equivalence classes). A test design need only select one element (a class representative) from each equivalence class for testing.

Wolfram Research has this definition:

An equivalence relation on a set X is a subset of , i.e., a collection R of ordered pairs of elements of X, satisfying certain properties. Write "xRy" to mean (x, y) is an element of R, and we say "x is related to y," then the properties are

1. Reflexive: aRa for all ,

2. Symmetric: aRb implies bRa for all

3. Transitive: aRb and bRc imply aRc for all ,

where these three properties are completely independent. Other notations are often used to indicate a relation, e.g., or .

Of course "less than or equal to" is not an equivalence relation because it is not a transitive relation. On the other hand, "equal to" is an equivalence relation, but a trivial one that does not help in narrowing down potential test cases. For any given software program the equivalence class technique begins with the definition of the appropriate relations among the variables, or among program steps, or what have you. Then the relations can be assessed for their transitive, symmetric and reflexive properties.

Consider then this excerpt from "Effective Software Testing: 50 Ways to Improve your Testing" (p.130) by Elfriede Dunstin:

"Equivalence partitioning identifies ranges of inputs and initial conditions that are expected to produce the same result. Equivalence partitioning relates to the commonality and variances among the different situations in which a system is expected to work. If situations are equivalent, or essentially similar, to one another, it is adequate to test only one of them, not all. Although equivalence is usually intuitively obvious, it is necessary to be careful about what is assumed to be equivalent.

Consider the following example, which demonstrates equivalence applied to boundaries:

A password field allows 8 digits; any more are invalid. Since values that are on the same side of the boundary are members of the same "equivalence class" there is no point to testing many members of the same equivalence class(e.g., passwords with 10 digits, 11 digits, 12 digits, etc.), since they will produce the same result."

While there is certainly an intuitive feel that some test cases are redundant because there is no difference in their relevant properties, this is not a definition of equivalence class. In fact, in the example, there is no good reason to suppose that 12 digit password entries, say, do not lead to some problem. Perhaps the field buffer overflows for more than 11 digits. There is no reason based on some intuitive notion of equivalence that will help with testing design in such a case.

For the example to work there would need to be some equivalence relation that can be defined over the set of possible password strings that will partition that set into disjoint non-null subsets. Then elements of the same subset would be equivalent and hence redundant with respect to testing. The set of all possible strings of characters of length 1 through length n is a very large set indeed. The example supposes this set can be partitioned into two disjoint subsets: the set of strings of length 8 or less (let's include the null string as it should also be tested as a possible password input), and its complement, the set of strings of length 9 or more. There is of course an equivalence relation that creates this partition. That is, some relation R exists that is transitive, reflexive and symmetric for any pair of elements in the set of strings of length 8 or less, but we haven't defined precisely what that relation is. Fortunately we don't have to. The fact that we can make a partition into disjoint subsets induces an equivalence relation.

Here is another example:

For each input, divide the input domain into sets of data (called equivalence sets), where all of the values in each set will cause the system to behave similarly. Determine the equivalence sets for a particular input by understanding the sets of conditions that effect the behavior of the requirement. You may find it helpful to keep the following guidelines in mind when creating equivalence classes:

If an input condition specifies a range, at least one valid (the set of values in the range) and two invalid equivalence sets (the set of values less than the lowest extreme of the range, and the set of values greater than the largest extreme) are defined.

If an input condition specifies a member of a set, then at least one valid (the set itself) and one invalid equivalence sets (the complement of the valid set) are defined.

If an input condition requires a specific value, then one valid (the set containing the value itself) and two invalid equivalence sets (the set of values less than, and the set greater than, the value) are defined.

Again there is no mention of the equivalence relation over the domain that defines the equivalence classes, but neither does there need to be. The misconception involved in using equivalence partitioning as a test design technique resides in the notion of "subjective feel" for equivalence classes. Unless we can assess the relations induced by the variables of the process flow steps in the software we should be hesitant about selecting equivalence classes and hence removing potential test cases.