- Write test cases from given software models using the following test design techniques. (K3)
- equivalence partitioning;
- boundary value analysis;
- decision tables;
- state transition testing.
- Understand the main purpose of each of the four techniques, what level and type of testing could use the technique, and how coverage may be measured. (K2)
- Understand the concept of use case testing and its benefits. (K2)
In this section we will look in detail at four specification-based or black-box techniques. These four techniques are K3 in the Syllabus – this means that you need to be able to use these techniques to design test cases. We will also cover briefly (not at K3 level) the specification-based technique of use case testing. In Section 4.4, we will look at the K3 structure-based techniques.
In this section, look for the definitions of the glossary terms: boundary value analysis, decision table testing, equivalence partitioning, state transition testing and use case testing.
The four specification-based techniques we will cover in detail are:
- equivalence partitioning;
- boundary value analysis;
- decision tables;
- state transition testing.
Note that we will discuss the first two together, because they are closely related.
4.3.1 Equivalence partitioning and boundary value analysis
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 commonsense approach to testing, so much so that most testers practice it informally even though they may not realize it. However, while it is better to use the technique 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.
This technique will be found in most testing books, including [Myers, 1979] and [Copeland, 2003]. 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.
For example, 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. For example, 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% interest 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.
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). 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 the three valid equivalence partitions are each 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? A naive tester (let’s call him Robbie) 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 Robbie would have got tired of it and thought that enough tests had been carried out). But look at what Robbie 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, Robbie 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. 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”.
Note also that the invalid partition may be invalid only in the context of crediting interest payments. An account that is overdrawn will require some different action.
