1 of 12 4 Equivalence partitioning and boundary value analysis revisited Equivalence partitioning (EP) and boundary value analysis (BVA) together are among the most popular and widely used techniques. They are easy to understand and used. However, in many cases, the related test selection is incorrectly used. This chapter revisits and puts EP and BVA techniques in a brand new framework 4.1 Equivalence partitioning The first step of EP is to partition the input domain D into sub-domains (equivalence classes) and then design tests with values from the sub-domains. The equivalence classes for partitions) are non-empty. disjoint, and the union of the partitions covers the entire domain D. Test designers produce equivalence dasses based on the specification. The equivalence classes are constructed in a way that the inputs a and belong to the same equivalence dass if and only if the behaviour of the test object for input and b are the same (which states that the program handles the test values from one class in the same way). If a and b test the same behaviour and the computation is wrong than both and will detect the bug. Therefore, one test case for each equivalence partition is enough, selecting the second is superfluous, it would add an extra cost. The test selection criteria for equivalence partitioning is to have at least one data from each partition Before we show how to create test cases that meet the EP test selection criteria, we need to define a fault assumption strategy. In fact, it is not enough to know that a test has failed, but it is necessary for the developers to find the bug(s) easily. Remember that the single fault assumption means that if we test an input range with a test case and it fail, we know which parameter value has been caused the fault. Suppose that there are requirements saying R1 The customer gets 10% price reduction if the price of the goods reaches 80 euros. R2 The VIP customers get 5% further price reduction. Let's design a test case TI - (price = 100, VIP true). If the result of the test is 87, nobody knows which requirement has been implemented incorrectly (maybe both). This test is made by applying multiply fault assumption. If the test case is T2 (price = 100, VIP = no), and the result is 87, then there is a very low chance that R2 is implemented incorrectly. A much higher chance is that 13% price reduction is implemented instead of 10 You, dear Reader, may think that you should apply single fault assumption all of the cases. Unfortunately, it is not true. By applying single fault assumption, the number of test cases will increase although one wants to keep them low. In general, there is no rule which strategy to apply. It is influenced by the size of the code, the complexity, the phase of the development, the risks, etc. For example, in low risky, simple 26