Test Technique – Equivalence Partitioning

Equivalence Partitioning

Equivalence partitioning is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.
In rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter “month”. The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.
        … -2 -1  0 1 ………….. 12 13  14  15 …..
      ————–|——————-|———————
 invalid partition 1     valid partition    invalid partition 2
The testing theory related to equivalence partitioning says that only one test case of each partition is needed to evaluate the behaviour of the program for the related partition. In other words it is sufficient to select one test case out of each partition to check the behaviour of the program. To use more or even all test cases of a partition will not find new faults in the program. The values within one partition are considered to be “equivalent”. Thus the number of test cases can be reduced considerably.
An additional effect by applying this technique is that you also find the so called “dirty” test cases. An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions. This would lead to a huge number of unnecessary test cases on the one hand, and a lack of test cases for the dirty ranges on the other hand.
The tendency is to relate equivalence partitioning to so called black box testing which is strictly checking a software component at its interface, without consideration of internal structures of the software. But having a closer look at the subject there are cases where it applies to grey box testing as well. Imagine an interface to a component which has a valid range between 1 and 12 like in the example above. However internally the function may have a differentiation of values between 1 and 6 and the values between 7 and 12. Depending on the input value the software internally will run through different paths to perform slightly different actions. Regarding the input and output interfaces to the component this difference will not be noticed, however in your grey-box testing you would like to make sure that both paths are examined. To achieve this it is necessary to introduce additional equivalence partitions which would not be needed for black-box testing. For this example this would be:
        … -2 -1  0 1 ….. 6 7 ….. 12 13  14  15 …..
      ————–|———|———-|———————
 invalid partition 1      P1         P2     invalid partition 2
                       valid partitions

To check for the expected results you would need to evaluate some internal intermediate values rather than the output interface.
Equivalence partitioning is no stand alone method to determine test cases. It has to be supplemented by boundary value analysis. Having determined the partitions of possible inputs the method of boundary value analysis has to be applied to select the most effective test cases out of these partitions.

WHY LEARN EQUIVALENCE PARTITIONING?

Equivalence partitioning drastically cuts down the number of test cases required to test a system reasonably. It is an attempt to get a good ‘hit rate’, to find the most errors with the smallest number of test cases.

DESIGNING TEST CASES USING EQUIVALENCE PARTITIONING

 To use equivalence partitioning, you will need to perform two steps
1)      Identify the equivalence classes.
2)      Design test cases

STEP 1: IDENTIFY EQUIVALENCE CLASSES

Take each input condition described in the specification and derive at least two equivalence classes for it. One class represents the set of cases which satisfy the condition (the valid class) and one represents cases which do not (the invalid class ).
Following are some general guidelines for identifying equivalence classes:
a) If the requirements state that a numeric value is input to the system and must be within a range of values, identify one valid class inputs which are within the valid range and two invalid equivalence classes inputs which are too low and inputs which are too high. For example, if an item in inventory can have a quantity of – 9999 to + 9999, identify the following classes:
1. one valid class: (QTY is greater than or equal to -9999 and is less than or equal to 9999). This is written as (- 9999 < = QTY < = 9999)
2. the invalid class (QTY is less than -9999), also written as (QTY < -9999)
3. the invalid class (QTY is greater than 9999) , also written as (QTY >9999)

b) If the requirements state that the number of items input by the system at some point must lie within a certain range, specify one valid class where the number of inputs is within the valid range, one invalid class where there are too few inputs and one invalid class where there are, too many inputs.

For example, specifications state that a maximum of 4 purchase orders can be registered against anyone product. The equivalence classes are : the valid equivalence class: (number of purchase orders is greater than or equal to 1 and less than or equal to 4 , also written as (1 < = no. of purchase orders < = 4)
the invalid class (no. of purchase orders> 4)
the invalid class (no. of purchase orders < 1)

c) If the requirements state that a particular input item match one of a set of values and each case will be dealt with the same way, identify a valid class for values in the set and one invalid class representing values outside of the set. For example, if the requirements state that a valid province code is ON, QU, and NB, then identify :
the valid class code is one of ON, QU, NB
the invalid class code is not one of ON, QU, NB

d) If the requirements state that a particular input item match one of a set of values and each case will be dealt with differently, identify a valid equivalence class for each element and only one invalid class for values outside the set. For example, if a discount code must be input as P for preferred customer, R for standard reduced rate, or N for none, and if each case is treated differently, identify
the valid class code = P
the valid class code = R
the valid class code = N
the invalid class code is not one of P, R, N

e) If you think any elements of an equivalence class will be handled differently than the others, divide the equivalence class to create an equivalence class with only these elements and an equivalence class with none of these elements. For example, a bank account balance may be from $0 up to $ 1,000,000, and balances $ 1,000 or over are not subject to service charges. Identify :
the valid class: ($ 0 < = balance < $ 1,000) i.e., balance is between 0 and $ 1,000 – not including $ 1,000
the valid class: ($ 1, 000 < = balance < = $ 1,000,000 i.e., balance is between $ 1,000 and $1,000,000 inclusive the invalid class: (balance < $ 0) the invalid class: (balance> $ 1,000,000)
A definition of Equivalence Partitioning from our software testing dictionary:

Equivalence Partitioning: An approach where classes of inputs are categorized for product or function validation. This usually does not include combinations of input, but rather a single state value based by class. For example, with a given function there may be several classes of input that may be used for positive testing. If function expects an integer and receives an integer as input, this would be considered as positive test assertion. On the other hand, if a character or any other input class other than integer is provided, this would be considered a negative test assertion or condition.