Equivalence partitioning (EP) is a specification-based or black-box technique. It can be applied at any level of testing and is often a good technique to use first.

• The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently), hence ‘equivalence partitioning’. Equivalence partitions are also known as equivalence classes – the two terms mean exactly the same thing.
• In equivalence-partitioning technique we need to test only one condition from each partition. This is because we are assuming that all the conditions in one partition will be treated in the same way by the software. If one condition in a partition works, we assume all of the conditions in that partition will work, and so there is little point in testing any of these others. Similarly, if one of the conditions in a partition does not work, then we assume that none of the conditions in that partition will work so again there is little point in testing any more in that partition.

For example, a savings account in a bank has a different rate of interest depending on the balance in the account. In order to test the software that calculates the interest due, we can identify the ranges of balance values that earn the different rates of interest.

For example, 3% rate of interest is given if the balance in the account is in the range of $0 to $100, 5% rate of interest is given if the balance in the account is in the range of $100 to $1000, and 7% rate of interest is given if the balance in the account is $1000 and above, we would initially identify three valid equivalence partitions and one invalid partition as shown below.

In the above example we have identified four partitions, even though the specification mentioned only three. This shows a very important task of the tester that is a tester should not only test what is in the specification, but should also think about things that haven’t been specified. In this case we have thought of the situation where the balance is less than zero.

We haven’t (yet) identified an invalid partition on the right, but this would also be a good thing to consider. In order to identify where the 7% partition ends, we would need to know what the maximum balance is for this account (which may not be easy to find out). In our example we have left this open for the time being. Note that non-numeric input is also an invalid partition (e.g. the letter ‘a’) but we discuss only the numeric partitions for now.

We have made an assumption here about what the smallest difference is between two values. We have assumed two decimal places, i.e. $100.00, but we could have assumed zero decimal places (i.e. $100) or more than two decimal places (e.g. $100.0000) In any case it is a good idea to state your assumptions – then other people can see them and let you know if they are correct or not.

When designing the test cases for this software we would ensure that all the three valid equivalence partitions are covered once, and we would also test the invalid partition at least once. So for example, we might choose to calculate the interest on balances of-$10.00, $50.00, $260.00 and $1348.00. If we hadn’t specifically identified these partitions, it is possible that at least one of them could have been missed at the expense of testing another one several times over.

Note that we could also apply equivalence partitioning to outputs as well. In this case we have three interest rates: 3%, 5% and 7%, plus the error message for the invalid partition (or partitions). In this example, the output partitions line up exactly with the input partitions. How would someone test this without thinking about the partitions?

An inexperienced tester (let’s call him Robbin) might have thought that a good set of tests would be to test every $50. That would give the following tests: $50.00, $100.00, $150.00, $200.00, $250.00, … say up to $800.00 (then Robbin would have got tired of it and thought that enough tests had been carried out). But look at what Robbin has tested: only two out of four partitions! So if the system does not correctly handle a negative balance or a balance of $1000 or more, he would not have found these defects – so the naive approach is less effective than equivalence partitioning.

At the same time, Robbin has four times more tests (16 tests versus our four tests using equivalence partitions), so he is also much less efficient. This is why we say that using techniques such as this makes testing both more effective and more efficient. Note that when we say a partition is ‘invalid’, it doesn’t mean that it represents a value that cannot be entered by a user or a value that the user isn’t supposed to enter. It just means that it is not one of the expected inputs for this particular field.

Other popular articles:

• What is Boundary value analysis in software testing?
• While testing why it is important to do both equivalence partitioning and boundary value analysis?
• Where to apply this test coverage in software testing?
• What are the types of coverage?
• What is Decision table in software testing? How to use, examples