Equivalence partitioning

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

It is a common sense approach to testing, so much so that most testers practise it informally even though they may not realize it. However, while it is better to use the tecnique informally than not at all, it is much better to use the technique in a formal way to attain the full benefits that it can deliver. 

The idea behind the 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. The equivalence-partitioning technique then requires that we need 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. Conversely, 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. 

Of course these are simplifying assumptions that may not always be right but if we write them down, at least it gives other people the chance to challenge the assumptions we have made and hopefully help to identify better partitions.

 If you have time, you may want to try more than one value from a partition, especially if you want to confirm a selection of typical user inputs.

• Ex: a savings account in a bank earns 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. 
• if a balance in the range $0 up to $100 has a 3%interest rate, 
• a balance over $100 and up to $1000 has a 5% inter-est rate,
• and balances of $1000 and over have a 7% interest rate, 
• we would initially identify three valid equivalence partitions and one invalid partition as shown below. 

Invalid partition        Valid (for 3% interest)         Valid (for 5%)                     Valid (for 7%) 
-$0.01                             $0.00 $100.00               $100.01 $999.99                    $1000.00

• Notice that we have identified four partitions here, even though the specification only mentions three. This illustrates a very important task of the tester - not only do we test what is in our specification, but we 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). 

•  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 the three valid equivalence partitions are each covered once, and we would also test the invalid partition at least once. 

Thre interests can be calculated fo the balances of-$10.00, $50.00, $260.00 and $1348.00.
If  the partitions were not sspecifically 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? A naive tester 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  yet only two out of four partitions were tested.

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 equiva-lence partitioning.  At the same time,there are four times more tests (16 tests versus the four tests using equivalence partitions), therefore it is also much less efficient! 


Note that when 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. 

The software should correctly handle values from the invalid partition, by replying with an error message such as 'Balance must be at least $0.00'.