In order to perform effective

a complete list of the component (under test) responses needs to be established. The responses could be in the form of returned values or the completion of an action, such as a database update or the firing of an event.

Given the complete set of inputs, with the corresponding system responses, a technique called boundary analysis can begin. Boundary analysis is concerned with identify any data values that would invoke a different system response. By way of example consider the ATM machine that gives out between $20 and $300 in cash, in $20 increments. The data boundaries for this ‘get cash’ function are:

1) Less than $20
2) $20 to $300
3) More than $300

In turn this means that we should include tests that are on the boundaries, that is $20 and $300.

In more general data processing terms an example might be a given date for a customer to make a payment. The requirement could be that if a customer is over 30 days late, then a 3% fee is charged and if over 60 days late a 5% fee is charged. In the previous example the boundaries, that would need specific test cases for, would be exactly 30 days late, exactly 31 days late, exactly 60 days late and exactly 61 days late. In addition other test cases would be designed but it is important to test exactly on and around the boundaries.

The concept of equivalence partitioning, another black box testing technique, follows from boundary analysis. The idea of equivalence partitioning is to identify system paths that are common, i.e. they will follow the same program (code) execution path. In this way, in the ATM example, it will not make any difference if $320, $340, $5,000 or any amount over $300 is entered as the path will be the same and that is to reject the transaction with a suitable message. Equally if $40 or $60 is entered the path should be the same, in that the money should be dispensed and the amount deducted from the account balance.

That said, in the ATM example, there is another data variable that needs to be considered for boundary analysis and equivalence partitioning. The customer balance is a critical variable to the boundaries and equivalence of code execution. The extra requirement is that the customer needs to have enough funds in his account, and this needs to be reflected in the test cases. For example if the customer has $200 in his account then the boundaries are now:

1) Less than $20
2) Between $20 and $200
3) Between $220 and $300
4) More than $300.

In this way only amounts in the $20 to $200 range are paid, as that is all that is in the account. So that our test cases should include amounts for $20, $200 and $300. Also there are now four equivalent partitions, in that the path through the code should be the same for each of the partitions (as listed in the boundaries 1 to 4 above).

Although the ATM example is simple the power of equivalence partitioning lies in the effective and efficient selection of test data (and test cases) with the idea to get the biggest bang for the buck in terms of executed (tested) code with the minimum number of test cases. Consider a commercial loan application that lends either fixed or variable loans to individuals, business partnerships and large corporations. By identifying the boundaries and equivalent partitions a set of test cases can be designed to exercise the main system paths with the minimum number of test cases.

In addition to so called valid boundaries, negative testing also can be designed when the boundaries are known. For example in the ATM example a negative test would be to try and enter $215 into the system (when the rule is $20 increments). In the commercial loan system example negative tests are more subtle in that in the loan application an individual may not be allowed to get a five year variable loan whilst a corporation might be allowed to get that type of loan. In the previous example a negative test would be to try and put a five year variable loan into the system for an individual.