Presentation is loading. Please wait.

Presentation is loading. Please wait.

Decision Table Based Testing

Similar presentations


Presentation on theme: "Decision Table Based Testing"— Presentation transcript:

1 Decision Table Based Testing
Decision table is based on logical relationships just as the truth table. Decision Table is a tool that helps us look at the combination of conditions Completeness of conditions Inconsistency of conditions

2 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 “binary” 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 : (e.g. R1 from reqs. or design says when all conditions are T, then actions a1, a2, and a5 should occur)

3 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 conditions, thus it provides a “completeness check.” The conditions in the decision table may be interpreted as the inputs of the table, and the actions may be thought of as outputs of the table. How do you decide how many rules must exist use the permutations of conditions and check against Requirements or Design Doc.?

4 Conditions? While you get the conditions from the requirement statements or design statements, what exactly do you look for? Requirement/Design statement that talks about inputs Requirement/Design statement that talks about processing Requirement/Design statement that talks about outputs Requirement/Design statement that talks about criteria

5 Triangle Problem Example (“short” form)
Pick input set, <a, b, c>, for each of the columns, or rules, below Assume a, b and c are all between 1 and 200 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 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 equivalent or all necessary Note the Impossible cases Req or Design should NOT have these cases

6 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” situation ---- A Triangle: 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 normal valid 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. Also, note that as we logically thought through this, it made us “look at’ the Requirement /Design statements more carefully.

7 Calendar Next-Date Problem Example
The Calendar next-date problem 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 Note we have not included the non-integer inputs here.

8 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? How are they dependent?

9 Decision Table for Next-Date
Month input R1 R2 R3 R4 R5 R6 R7 R8 Remember : Condition 1: 1 < = m <= 12 Condition 2: m < 1 Condition 3: m > 12 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 conditions 2 or 3, not both, can be true. So, rule R5 can be eliminated and we keep R6 and R7. c) Not all three conditions can be false. So rule R8 can be eliminated. That leaves only 3 conditions R4, R6, and R7 (resembles “exclusive OR” ?! )

10 Decision Table for Next-Date with Actions
Month input R1 R2 R3 R4 R5 R6 R7 R8 Remember : Condition 1: 1 < = m <= 12 Condition 2: m < 1 Condition 3: m > 12 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 Assume actions defined in the requirements doc. 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 R perhaps, a Specification or Design error ?

11 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


Download ppt "Decision Table Based Testing"

Similar presentations


Ads by Google