Equivalence Class Testing-Black Box Software Testing Techniques
The use of equivalence classes as the basis for functional testing and is appropriate in situations like:
a) When exhaustive testing is desired.
b) When there is a strong need to avoid redundancy.
The above are not handled by BVA technique as we can see massive redundancy in the tables of test cases. In this technique, the input and the output domain is divided into a finite number of equivalence classes.
Then, we select one representative of each class and test our program against it. It is assumed by the tester that if one representative from a class is able to detect error then why should he consider other cases. Furthermore, if this single representative test case did not detect any error then we assume that no other test case of this class can detect error. In this method we consider both valid and invalid input domains. The system is still treated as a black-box meaning that we are not bothered about its internal logic.
The idea of equivalence class testing is to identify test cases by using one element from each equivalence class. If the equivalence classes are chosen wisely, the potential redundancy among test cases can be reduced.
Types of equivalence class testing:
Following four types of equivalence class testing are presented here
1) Weak Normal Equivalence Class Testing.
2) Strong Normal Equivalence Class Testing.
3) Weak Robust Equivalence Class Testing.
4) Strong Robust Equivalence Class Testing.
1) Weak Normal Equivalence Class Testing:
The word ‘weak’ means ‘single fault assumption’. This type of testing is accomplished by using one variable from each equivalence class in a test case. We would, thus, end up with the weak equivalence class test cases as shown in the following figure.
Each dot in above graph indicates a test data. From each class we have one dot meaning that there is one representative element of each test case. In fact, we will have, always, the same number of weak equivalence class test cases as the classes in the partition.
2) Strong Normal Equivalence Class Testing:
This type of testing is based on the multiple fault assumption theory. So, now we need test cases from each element of the Cartesian product of the equivalence classes, as shown in the following figure.
Just like we have truth tables in digital logic, we have similarities between these truth tables and our pattern of test cases. The Cartesian product guarantees that we have a notion of “completeness” in following two ways
a) We cover all equivalence classes.
b) We have one of each possible combination of inputs.
3) Weak Robust Equivalence Class Testing:
The name for this form of testing is counter intuitive and oxymoronic. The word’ weak’ means single fault assumption theory and the word ‘Robust’ refers to invalid values. The test cases resulting from this strategy are shown in the following figure.
Following two problems occur with robust equivalence testing.
a) Very often the specification does not define what the expected output for an invalid test case should be. Thus, testers spend a lot of time defining expected outputs for these cases.
b) Strongly typed languages like Pascal, Ada, eliminate the need for the consideration of invalid inputs. Traditional equivalence testing is a product of the time when languages such as FORTRAN, C and COBOL were dominant. Thus this type of error was quite common.
4) Strong Robust Equivalence Class Testing:
This form of equivalence class testing is neither counter intuitive nor oxymoronic, but is just redundant. As explained earlier also, ‘robust’ means consideration of invalid values and the ‘strong’ means multiple fault assumption. We obtain the test cases from each element of the Cartesian product of all the equivalence classes as shown in the following figure.
We find here that we have 8 robust (invalid) test cases and 12 strong or valid inputs. Each one is represented with a dot. So, totally we have 20 test cases (represented as 20 dots) using this technique.
Guidelines for Equivalence Class Testing:
The following guidelines are helpful for equivalence class testing
1) The weak forms of equivalence class testing (normal or robust) are not as comprehensive as the corresponding strong forms.
2) If the implementation language is strongly typed and invalid values cause run-time errors then there is no point in using the robust form.
3) If error conditions are a high priority, the robust forms are appropriate.
4) Equivalence class testing is approximate when input data is defined in terms of intervals and sets of discrete values. This is certainly the case when system malfunctions can occur for out-of-limit variable values.
5) Equivalence class testing is strengthened by a hybrid approach with boundary value testing (BVA).
6) Equivalence class testing is used when the program function is complex. In such cases, the complexity of the function can help identify useful equivalence classes.
7) Strong equivalence class testing makes a presumption that the variables are independent and the corresponding multiplication of test cases raises issues of redundancy. If any dependencies occur, they will often generate “error” test cases.
8) Several tries may be needed before the “right” equivalence relation is established.
9) The difference between the strong and weak forms of equivalence class testing is helpful in the distinction between progression and regression testing.