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
Components of a Decision Table
rules
R1
R2 R3 R4 R5 R6 R7 R8
C1
T
T
T
T
F
F
F
F
“binary”
C2
conditions
C3
T
T
F
F
T
T
F
F
T
F
T
F
T
F
T
F
a1
x
x
x
a2
x
a5
x
actions taken
x
x
a4
x
x
x
actions a3
values of conditions
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)
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.?
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
Triangle Problem Example (“short” form)
Assume a, b and c are
all between 1 and 200
Pick input set, <a, b, c>, for each of the
columns, or rules, below
R1
R2 R3
R4 R5 R6 R7 R8 R9 R10 R11
1. a < b + c
2. b < a + c
3. c < a + b
F T T
- F T
- - F
T T T T T T T
T T T T T T T
T T T T T T T
T
T
T
4. a = b
5. a = c
6. b = c
-
T T T T F F F
T T F F T T F
T F T F T F T
F
F
F
1. Not triangle
1.
2.
3.
4.
Scalene
Isosceles
Equilateral
“impossible”
Req or Design should NOT
have these cases
-
-
X X X
X
X
X X
X
X X
X
equivalent or
all necessary
Note the
Impossible cases
How Many Test Cases for Triangle Problem?
•
There is the “invalid” situation --- Not a Triangle:
1.
2.
•
There is the “valid” situation ---- A Triangle:
1.
2.
3.
•
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 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.
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.
A Decision Table for Next-Date
Month input
Condition 1
T
T
T
T
F
F
F
F
Condition 2
T
T
F
F
T
T
F
F
Condition 3
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?
Decision Table for Next-Date
√
Month input
√ √
R1 R2 R3 R4 R5 R6 R7 R8
Condition 1
T
T
T
T
F
F
F
F
Condition 2
T
T
F
F
T
T
F
F
Condition 3
T
F
T
F
T
F
T
F
Remember :
Condition 1: 1 < = m <= 12
Condition 2: m < 1
Condition 3: m > 12
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” ?! )
Decision Table for Next-Date with Actions
√
Month input
√ √
R1 R2 R3 R4 R5 R6 R7 R8
Condition 1
T
T
T
T
F
F
F
F
Condition 2
T
T
F
F
T
T
F
F
Condition 3
T
F
T
F
T
F
T
F
Action 1
-
-
-
X
-
X
X
-
Action 2
-
-
X X
-
-
-
-
Remember :
Condition 1: 1 < = m <= 12
Condition 2: m < 1
Condition 3: m > 12
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 R3 ---- perhaps, a Specification or Design error ?
Advantages/Disadvantages of Decision Table
•
Advantages: (check completeness & consistency)
1. Allow us to start with a “complete” view, with no
consideration of dependence
2. Allow us to look at and consider “dependence,”
“impossible,” and “not relevant” situations and
eliminate some test cases.
3. Allow us to detect potential error in our
Specifications
•
Disadvantages:
1. 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
2. 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