Equivalence Class Partitioning

If a tester is viewing the software-under-test as a black box with welldefined

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 softwareunder-

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 [5].

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:

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

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

of detecting a defect.

3. 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 [1]. 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.

1. The tester must consider both valid and invalid equivalence classes.

Invalid classes represent erroneous or unexpected inputs.

2. Equivalence classes may also be selected for output conditions.

3. 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.

4. 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 of 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 4.2. 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

FIG. 4.2

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.

1. Each equivalence class should be assigned a unique identifier. A simple

integer is sufficient.

2. 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.

3. 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.

4 . 6 Boundary Value Analysis

Equivalence class partitioning gives the tester a useful tool with which

to develop black box based-test cases for the software-under-test. The

method requires that a tester has access to a specification of input/output

behavior for the target software. The test cases developed based on equivalence

class partitioning can be strengthened by use of an another technique

called boundary value analysis. With experience, testers soon realize

that many defects occur directly on, and above and below, the edges

of equivalence classes. Test cases that consider these boundaries on both

the input and output spaces as shown in Figure 4.3 are often valuable in

revealing defects.

Whereas equivalence class partitioning directs the tester to select test

cases from any element of an equivalence class, boundary value analysis

requires that the tester select elements close to the edges, so that both the

upper and lower edges of an equivalence class are covered by test cases.

As in the case of equivalence class partitioning, the ability to develop highquality

test cases with the use of boundary values requires experience.

The rules-of-thumb described below are useful for getting started with

boundary value analysis.

1. If an input condition for the software-under-test is specified as a range

of values, develop valid test cases for the ends of the range, and invalid

test cases for possibilities just above and below the ends of the

range.

For example if a specification states that an input value for a

module must lie in the range between _1.0 and _1.0, valid tests

that include values for ends of the range, as well as invalid test cases

for values just above and below the ends, should be included. This

would result in input values of _1.0, _1.1, and 1.0, 1.1.

Boundaries of an equivalence

partition.

2. If an input condition for the software-under-test is specified as a number

of values, develop valid test cases for the minimum and maximum

numbers as well as invalid test cases that include one lesser and one

greater than the maximum and minimum.

For example, for the real-estate module mentioned previously

that specified a house can have one to four owners, tests that include

0,1 owners and 4,5 owners would be developed.

The following is an example of applying boundary value analysis

to output equivalence classes. Suppose a table of 1 to 100 values is

to be produced by a module. The tester should select input data to

generate an output table of size 0,1, and 100 values, and if possible

101 values.

3. If the input or output of the software-under-test is an ordered set,

such as a table or a linear list, develop tests that focus on the first and

last elements of the set.

It is important for the tester to keep in mind that equivalence class

partitioning and boundary value analysis apply to testing both inputs and

outputs of the software-under-test, and, most importantly, conditions are

not combined for equivalence class partitioning or boundary value analysis.

Each condition is considered separately, and test cases are developed

to insure coverage of all the individual conditions