Equivalence Class Partitioning , Part II

Gieno   Equivalence Class Partitioning , Part II

Jorgensen [2] takes a different approach and defines a formula for calculating a specific number of tests for “weak” equivalence class testing and for “strong” equivalence class testing. The “weak” equivalence class testing approach requires that one element from each equivalence class subset is exercised independently in a test. The total number of equivalence class test cases is equal to the largest number of equivalence class subsets in any union of subsets plus the total number of invalid equivalence class subsets. Using the example function above and applying the formula for “weak” equivalence class testing the total number of tests is 17. The “weak” valid equivalence class tests include:

Test Case	Argv1	Argv2
1	EQA1	EQB1
2	EQA2	EQB2
3	EQA3	EQB1
4	EQA4	EQB2

 

While this approach exercises each valid equivalence class independently which would provide more thorough coverage, in this example since EQ_A4 must be a characteristic of EQ_A1, EQ_A2, and EQ_A3, the number of tests could reasonably be reduced to 3 by creating a union between EQ_A1, EQ_A2, and EQ_A3, and EQ_A4.

 

The number of invalid equivalence class tests is equal to the total number of invalid classes. A formula to calculate the minimum number of tests for “weak” equivalence class testing is: Total EQ_Tests = MaxNum EQ_Valid + Total EQ_Invalid

So, in the example above the total number of tests is: MaxNum EQ_Valid + Total EQ_Invalid = 4 + 6 = 10 tests for weak equivalence class testing

 

Jorgensen also describes “strong” equivalence class testing in which each test includes every possible combination of subsets of values. The “strong” equivalence class method produces a set of test cases equal to the Cartesian product of each partition’s equivalence class subsets. Thus, in the example above the total number of test cases for “strong” equivalence class testing is Valid EQ Argv1 * Valid EQ Argv2 = (EQ_A1 È EQ_A2 È EQ_A3, È EQ_A4) * (EQ_B1 È EQ_B2) = 4 * 2 = 8. The complete set of “strong” valid equivalence class test cases is listed in the table below.

Test Case	Argv1	Argv2
1	EQA1	EQB1
2	EQA1	EQB2
3	EQA2	EQB1
4	EQA2	EQB2
5	EQA3	EQB1
6	EQA3	EQB2
7	EQA4	EQB1
8	EQA4	EQB2

 

Again, this does not include the invalid equivalence class tests which are equal to the total number of invalid classes. A formula to calculate the minimum number of tests for “strong” equivalence class testing is:

 

Total EQ_Tests = ((Param1 EQ_Valid) * (Param2 EQ_Valid) etc.)+ Total EQ_Invalid

Jorgensen states “strong” equivalence class testing in which all combinations in which at least one combination of each possible input has been tested guarantees a sense of completeness. Although “strong” equivalence class testing tests every possible combination, it may be considered over-testing. Numerous case studies at Microsoft and within the industry clearly demonstrate testing all possible combinations is unlikely to reveal any errors or changes in functionality beyond a carefully constructed array of combinations using orthogonal arrays or pair-wise testing analysis and expert knowledge.

 

Although this example focuses on defining the equivalence classes for an input domain space, equivalence class partitioning can also be used to define valid and invalid classes for output equivalence classes. For example, in the triangle problem there are essentially four possible outputs:

 

·         Sides A, B, and C equate to an equilateral triangle

·         Sides A, B, and C equate to an isosceles triangle

·         Sides A, B, and C equate to a scalene triangle

·         Sides A, B, and C do not form a valid triangle 

Using output condition it is possible to define a more robust set of tests using the EQ Worksheet.  

Input/Output  Condition	Valid Equivalence Classes	Invalid Equivalence Classes
Equilateral	A = B = C
Isosceles	A = B ¹ C	A = B + C
Isosceles		A > B + C
Isosceles		B = A + C
ETC…	…	…

 

In order to be successful with equivalence class partitioning the test engineer must have an excellent understanding of the domain space. It is up to the test engineer to determine the equivalence relationships for each set of parameters. There is no magic formula for equivalence class partitioning. The test engineer must understand the properties of the values being evaluated and how those values are processed in order to derive an accurate set of equivalence class tests that achieve a reasonable degree of confidence in the program without over-testing.

 

REFERENCES:

[1] Glenford J. Myers. The Art of Software Testing 1979

[2] Paul C. Jorgensen. Software Testing: A Craftsman’s Approach 1995