Equivalence Class Partitioning

Equivalence Class Partitioning

If a tester is viewing the software-under-test as a black box with well- defined inputs and outputs, a good approach to selecting test inputs is to use a method called equivalence class partitioning. Equivalence class partitioning results in a partitioning of the input domain of the software under test. The technique can also be used to partition the output domain, but this is not a common usage. The finite number of partitions or equivalence classes that result allow the tester to select a given member of an equivalence class as a representative of that class. It is assumed that all members of an equivalence class are processed in an equivalent way by the target software.

Using equivalence class partitioning a test value in a particular class is equivalent to a test value of any other member of that class. Therefore, if one test case in a particular equivalence class reveals a defect, all the other test cases based on that class would be expected to reveal the same defect. We can also say that if a test case in a given equivalence class did not detect a particular type of defect, then no other test case based on that class would detect the defect (unless a subset of the equivalence class falls into another equivalence class, since classes may overlap in some cases). A more formal discussion of equivalence class partitioning is given in Beizer.

Based on this discussion of equivalence class partitioning we can say that the partitioning of the input domain for the software-under-test using this technique has the following advantages:

It eliminates the need for exhaustive testing, which is not feasible.

It guides a tester in selecting a subset of test inputs with a high probability of detecting a defect.

It allows a tester to cover a larger domain of inputs/outputs with a smaller subset selected

from an equivalence class.

Most equivalence class partitioning takes place for the input domain. How does the tester identify equivalence classes for the input domain? One approach is to use a set of what Glen

Myers calls ―interesting‖ input conditions. The input conditions usually come from a description in the specification of the software to be tested. The tester uses the conditions to partition the input domain into equivalence classes and then develops a set of tests cases to cover (include) all the classes. Given that only the information in an input/output specification is needed, the tester can begin to develop black box tests for software early in the software life cycle in parallel with analysis activities (see Principle 11, Chapter 2). The tester and the analyst interact during the analysis phase to develop (i) a set of testable requirements, and (ii) a correct and complete input/output specification. From these the tester develops, (i) a high-level test plan, and (ii) a preliminary set of black box test cases for the system. Both the plan and the test cases undergo further development in subsequent life cycle phases. The V-Model as described in Chapter 8 supports this approach.

There are several important points related to equivalence class partitioning that should be made to complete this discussion.

The tester must consider both valid and invalid equivalence classes. Invalid classes represent erroneous or unexpected inputs.

Equivalence classes may also be selected for output conditions.

The derivation of input or outputs equivalence classes is a heuristic process. The conditions that are described in the following paragraphs only give the tester guidelines for identifying the partitions. There are no hard and fast rules. Given the same set of conditions, individual testers may make different choices of equivalence classes. As a tester gains experience he is more able to select equivalence classes with confidence.

In some cases it is difficult for the tester to identify equivalence classes. The conditions/boundaries that help to define classes may be absent, or obscure, or there may seem to be a very large or very small number of equivalence classes for the problem domain. These difficulties may arise from an ambiguous, contradictory, incorrect, or incomplete specification and/or requirements description. It is the duty of the tester to seek out the analysts and meet with them to clarify these documents. Additional contact with the user/client group may be required. A tester should also realize that for some software problem domains defining equivalence classes is inherently difficult, for example, software that needs to utilize the tax code.

Myers suggests the following conditions as guidelines for selecting input equivalence classes [1]. Note that a condition is usually associated with a particular variable. We treat each condition separately. Test cases, when developed, may cover multiple conditions and multiple variables.

List o f Conditions

1. If an input condition for the software-under-test is specified as a range of values, select one valid equivalence class that covers the allowed range and two invalid equivalence classes, one outside each end of the range.‘‘

For example, suppose the specification for a module says that an input, the length of a widget in millimeters, lies in the range 1-499; then select one valid equivalence class that includes all values from 1 to 499. Select a second equivalence class that consists of all values less than 1, and a third equivalence class that consists of all values greater than 499.

2. If an input condition for the software-under-test is specified as a number of values, then select one valid equivalence class that includes the allowed number of values and two invalid equivalence classes that are outside each end of the allowed number.‘‘

For example, if the specification for a real estate-related module say that a house can have one to four owners, then we select one valid equivalence class that includes all the valid number of owners, and then two invalid equivalence classes for less than one owner and more than four owners.

3. If an input condition for the software-under-test is specified as a set of valid input values, then select one valid equivalence class that contains all the members of the set and one invalid equivalence class for any value outside the set.‘‘

For example, if the specification for a paint module states that the colors RED, BLUE, GREEN and YELLOW are allowed as inputs, then select one valid equivalence class that includes the set RED, BLUE, GREEN and YELLOW, and one invalid equivalence class for all other inputs.

4. If an input condition for the software-under-test is specified as a ―must be‖ condition, select one valid equivalence class to represent the ―must be‖ condition and one invalid class that does not include the ―must be‖ condition.‘‘

For example, if the specification for a module states that the first character of a part identifier must be a letter, then select one valid equivalence class where the first character is a letter, and one invalid class where the first character is not a letter.

5.  If the input specification or any other information leads to the belief that an element in an equivalence class is not handled in an identical way by the software-under-test, then the class should be further partitioned into smaller equivalence classes.‘‘

To show how equivalence classes can be derived from a specification, consider an example

in Figure. This is a specification for a module that calculates a square root. The specification describes for the tester conditions relevant to the

Function

square_root message (x:real) when x>_0.0

reply (y:real)

where y >_0.0 & approximately (y*y,x)

otherwise reply exception imaginary_square_root end function

A specification of a square root function.

input/output variables x and y. The input conditions are that the variable x must be a real number and be equal to or greater than 0.0. The conditions for the output variable y are that it must be a real number equal to or greater than 0.0, whose square is approximately equal to x. If x is not equal to or greater than 0.0, then an exception is raised. From this information the tester can easily generate both invalid and valid equivalence classes and boundaries. For example, input equivalence classes for this module are the following:

EC1. The input variable x is real, valid. EC2. The input variable x is not real, invalid. EC3. The value of x is greater than 0.0, valid. EC4. The value of x is less than 0.0, invalid.

Because many organizations now use some type of formal or semiformal specifications, testers have a reliable source for applying the input/output conditions described by Myers.

After the equivalence classes have been identified in this way, the next step in test case design is the development of the actual test cases. A good approach includes the following steps.

Each equivalence class should be assigned a unique identifier. A simple integer is sufficient. Develop test cases for all valid equivalence classes until all have been covered by (included

in) a test case. A given test case may cover more than one equivalence class.

Develop test cases for all invalid equivalence classes until all have been covered individually. This is to insure that one invalid case does not mask the effect of another or

prevent the execution of another.

An example of applying equivalence class partitioning will be shown in the next section.