Equivalence Class Testing Use the mathematical concept of equivalence class to generate test cases for largely Functional (Black-box) testing The key goals for equivalence class testing are: completeness of test coverage lessen duplication ( or effort) of test coverage

Equivalence Class Recall a partitioning of a set, A, is to divide the set A into ( a1, a2, - - - -, an ) subsets such that: a1 U a2 U - - - - U an = A (completeness) for any i and j, ai ∩ aj = Ø (no duplication) Equivalence relation is a relation defined on the set A such that it is reflexive, transitive, and symmetric Equivalence class testing develops test cases via the partitioning of the input/output/predicate variable’s value set into classes (subsets) using some equivalence relation.

Equivalence Class Test Cases Consider a numerical input variable, I, whose values may range from -200 through +200. Then a possible partitioning is: -200 to 0 1 to 200 Define “= sign” as the equivalence relation, R, defined over the input variable’s value set X. Then one partitioning will be: -200 to -1 (negative sign) 0 (no sign) 1 to 200 (positive sign) “= sign” relation is an equivalence relation: (let € be “element of”) reflexive : -2 € X then (-2, -2) € R symmetric : (3, 5) € R, then (5, 3) € R transitive: (-5, -7) € R and (-7, -200) € , then (-5, -200) € R A sample equivalence test set with this relation would be ( -5, 0, 8)

Weak Normal Equivalence testing Assumes the “independence of input variables.” e.g. If there are 2 input variables, these input variables are independent of each other. Partition the test cases of each input variable separately into different equivalence classes. Choose the test case from each of the equivalence classes for each input variable independently of the other input variable

Example of : Weak Normal Equivalence testing Assume the equivalence partitioning of input X is 1 to 10; 11 to 20, 21 to 30 and the equivalence partitioning of input Y is 1 to 5; 6 to 10; 11;15; and 16 to 20 X We have covered everyone of the 3 equivalence classes for input X. 30 20 10 1 Y 1 5 10 15 20 General rule for # of test cases? What do you think? We have covered each of the 4 equivalence classes for input Y.

Strong Normal Equivalence testing This is the same as the weak normal equivalence testing except for “dependence” among the inputs All the combinations of equivalence classes of the variables must be included.

Example of : Strong Normal Equivalence testing Assume the equivalence partitioning of input X is 1 to 10; 11 to 20, 21 to 30 and the equivalence partitioning of input Y is 1 to 5; 6 to 10; 11;15; and 16 to 20 X 30 We have covered everyone of the 3 x 4 Cartesian product of equivalence classes 20 10 1 Y 1 5 10 15 20 General rule for # of test cases? What do you think?

Weak Robust Equivalence testing Up to now we have only considered partitioning the valid input space. “Weak robust” is similar to “weak normal” equivalence test except that the invalid input variables are now considered. A note about considering invalid input is that there may not be any definition specified for the different invalid inputs - - - making considering the output as the defining process for equivalence classes a bit more difficult.

Example of : Weak Robust Equivalence testing Assume the equivalence partitioning of input X is 1 to 10; 11 to 20, 21 to 30 and the equivalence partitioning of input Y is 1 to 5; 6 to 10; 11;15; and 16 to 20 We have covered everyone of the 5 equivalence classes for input X. X 30 20 10 1 Y 1 5 10 15 20 We have covered each of the 6 equivalence classes for input Y.

Strong Robust Equivalence testing - - - assumes dependency of input variables “Strong robust” is similar to “strong normal” equivalence test except that the invalid input variables are now considered.

Example of : Strong Robust Equivalence testing Assume the equivalence partitioning of input X is 1 to 10; 11 to 20, 21 to 30 and the equivalence partitioning of input Y is 1 to 5; 6 to 10; 11;15; and 16 to 20 X 30 We have covered everyone of the 5 x 6 Cartesian product of equivalence classes (including invalid inputs) 20 10 1 Y 1 5 10 15 20

Sample Problem Descriptions Triangle Problem: Develop a program which will accept 3 input integers to represent 3 sides of a triangle. Based on the values of the inputs, the program will output one of the following: Not a triangle Isosceles triangle Equilateral triangle Scalene triangle Date Problem: Develop a program that when given a date will output the proper date for the next day.

Equivalence class Definition Note that the examples so far focused on defining input variables without considering the output variables. For the “triangle problem,” we are interested in 4 questions: Is it a triangle? Is it an isosceles? Is it a scalene? Is it an equilateral? We may define the input test data by defining the equivalence class through the 4 output groups: input sides <a, b, c> do not form a triangle input sides <a, b ,c> form an isosceles triangle input sides <a, b, c> form a scalene triangle input sides <a, b, c> form an equilateral triangle

Weak Normal Equivalence Test Cases for Triangle Problem “valid” inputs: 1<= a <= 200 1<= b <= 200 1<= c <= 200 and for triangle: a < b + c b < a + c c < b + a inputs output a b c Not triangle 35 10 4 Equilateral 35 35 35 Valid Outputs Isosceles 24 24 7 Equilateral Isosceles Not Triangle Scalene 35 18 24 Scalene

Strong Normal Equivalence Test Cases for Triangle Problem Since there is no further sub-intervals inside the valid inputs for the 3 sides a, b, and c, Strong Normal Equivalence is the same as the Weak Normal Equivalence

Weak Robust Equivalence Test Cases for Triangle Problem <200,200,200> Now, include the “invalid” inputs Valid Outputs <1, 1, 1> Equilateral Include 6 invalid test case in addition to Weak Normal above: below: <201, 45, 50 > < -5, 76, 89 > <45, 204, 78 > < 56, -5, 89 > <50, 78, 208 > < 56, 89, 0 > Isosceles Not Triangle Scalene

Strong Robust Equivalence Test Cases for Triangle Problem Similar to Weak robust, but all combinations of “invalid” inputs but be included. Look at the “cube” figure and consider the corners (two diagonal ones) Consider one of the corners: there should be (23 – 1) = 7 cases of “invalids” < 201, 201, 201 > < 50 , 201, 50 > < 201, 201, 50 > < 50 , 201, 201 > < 201, 50 , 201 > < 50, 50 , 201 > < 201, 50 , 50 > There will be 7 more “invalids” when we consider the other corner , <0,0,0 >

Decision Table Based Testing Decision table is based on logical relationships just as the truth table. It is a tool that helps us look at the “completeness” and “consistency” of combination of conditions

Components of a Decision Table rules R1 R2 R3 R4 R5 R6 R7 R8 T T T T F F F F C1 C2 C3 values of conditions conditions T T F F T T F F T F T F T F T F a1 a2 a3 a4 a5 x x x x x x actions taken x x actions x x x x x x Read a Decision Table by columns of rules : R1 says when all conditions are T, then actions a1, a2, and a5 occur

Conditions in Decision Table The conditions in the decision table may take on any number of values. When it is binary, then the decision table conditions are just like a truth table set of conditions. The decision table allows the iteration of all the combinations of values of the condition, thus it provides a “completeness check.” The conditions in the decision table may be interpreted as the inputs to the table, and the actions may be thought of as outputs from the table.

Triangle Problem Example Pick input <a, b, c> for each of the columns Assume a, b and c are all between 1 and 200 a < b + c b < a + c c < a + b a = b a = c b = c F T T T T T T T T T T - F T T T T T T T T T - - F T T T T T T T T - - - T T T T F F F F - - - T T F F T T F F - - - T F T F T F T F Not triangle Scalene Isosceles Equilateral “impossible” X X X X X X X X X X Note the Impossible cases

How Many Test Cases for Triangle Problem? There is the “invalid situation” --- not a triangle: There are 3 test conditions in the Decision table Note the “-” entries, which represents “don’t care,” when it is determined that the input sides <a, b, c> do not form a triangle There is the “valid” triangle situation: There are 3 types of valid; so there are 23 = 8 test conditions But there are 3 “impossible” situations So there are only 8 – 3 = 5 test conditions So, for values of a, b, and c, we need to come up with 8 sets of <a, b, c> to test the (3 + 5) = 8 test conditions.

Calendar Next-Date Problem The Calendar next-date problem (given a calendar date input, output the “next” day date) has many constraints, one of which deals with the value of the month: Condition 1 : 1 <= month <= 12 Condition 2 : month < 1 Condition 3 : month > 12

A Decision Table for Next-Date Month input Condition 1 Condition 2 Condition 3 T T T T F F F F T T F F T T F F T F T F T F T F There are 23 = 8 test conditions (8 columns) for the month value. But ------- are these really “independent” conditions ?

Decision Table for Next-Date √ √ Remember : Condition 1: 1 < = m <= 12 Condition 2: m < 1 Condition 3: m > 12 √ Month input R1 R2 R3 R4 R5 R6 R7 R8 Condition 1 Condition 2 Condition 3 T T T T F F F F T T F F T T F F T F T F T F T F Note that: a) If condition 1 is true, then conditions 2 and 3 must both be false. So Rules 1 – 4 is reduced to just R4. b) If condition 1 is false, then only one of the condition 2 or 3, not both, can be true. So, rule R5 can be eliminated. c) Not all three conditions can be false (no non-integers). So rule R8 can be eliminated. That leaves only 3 conditions ---- R4, R6, and R7

Decision Table for Next-Date with Actions √ √ √ Remember : Condition 1: 1 < = m <= 12 Condition 2: m < 1 Condition 3: m > 12 Month input R1 R2 R3 R4 R5 R6 R7 R8 Condition 1 Condition 2 Condition 3 T T T T F F F F T T F F T T F F T F T F T F T F Action 1 Action 2 - - - X - X X - - - X X - - - - Note that R3 has an action defined in the Decision Table. This should trigger a question because the condition can not happen. There should be no action defined for R3 ---- specification error ?

Advantages/Disadvantages of Decision Table Advantages: (check completeness & consistency) Allow us to start with a “complete” view, with no consideration of dependence Allow us to look at and consider “dependence,” “impossible,” and “not relevant” situations and eliminate some test cases. Allow us to detect potential error in our Specifications Disadvantages: Need to decide (or know) what conditions are relevant for testing - - - this may require Domain knowledge e.g. need to know leap year for “next date” problem in the book Scaling up can be massive: 2n rules for n conditions - - - that’s if the conditions are binary and gets worse if the values are more than binary

A General Discussion on Functional (Black-box) Testing What are some of the concerns of testers ? Have we got enough time to test (effort)? Have we tested all the areas (coverage & efficiency)? Are we discovering the defects (effectiveness)?

Testing (Effort) = Time to develop each test case = # of Test cases sophistication Boundary Value Equivalence Class Decision Table