1. ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis

2. Overview Functional Testing Boundary Value Testing (BVT)
Boundary Value Analysis
Robustness Testing
Worst Case Testing
Special Value Testing
Equivalence Class Testing
Weak Equivalence Class Testing
Strong Equivalence Class Testing
Traditional Equivalence Class testing
Decision Table Based testing
Decision Tables
Technique
Examples

3. Decision Tables - General
Decision tables are a precise yet compact way to model complicated logic. Decision tables, like if-then-else and switch-case statements, associate conditions with actions to perform. But, unlike the control structures found in traditional programming languages, decision tables can associate many independent conditions with several actions in an elegant way. “

4. Decision Tables - Usage
Decision tables make it easy to observe that all possible conditions are accounted for.
Decision tables can be used for:
Specifying complex program logic
Generating test cases (Also known as logic-based testing)
Logic-based testing is considered as:
structural testing when applied to structure (i.e. control flowgraph of an implementation).
functional testing when applied to a specification.

5. Decision Tables - Structure
Conditions - (Condition stub)
Condition Alternatives – (Condition Entry)
Actions – (Action Stub)
Action Entries
Each condition corresponds to a variable, relation or predicate
Possible values for conditions are listed among the condition
alternatives
Boolean values (True / False) – Limited Entry Decision Tables
Several values – Extended Entry Decision Tables
Don’t care value
Each action is a procedure or operation to perform
The entries specify whether (or in what order) the action is to be
performed

6. To express the program logic we can use a limited-entry decision table consisting of 4 areas called the condition stub, condition entry, action stub and the action entry:
Condition entry
Rule1
Rule2
Rule3
Rule4
Condition1
Yes No
Condition2 X
Condition3
Condition4
Action1
Action2
Action3
Condition
stub
Action stub
Action Entry

7. We can specify default rules to indicate the action to be taken when none of the other rules apply.
When using decision tables as a test tool, default rules and their associated predicates must be explicitly provided.
Rule5
Rule6
Rule7
Rule8
Condition1 X No
Yes
Condition2
Condition3
Condition4
Default action

8. Decision Table - Example
Conditions
Printer does not print Y N
A red light is flashing
Printer is unrecognized
Actions
Heck the power cable X
Check the printer-computer cable
Ensure printer software is installed
Check/replace ink
Check for paper jam
Printer Troubleshooting

9. Decision Table Example

10. Decision Table Development Methodology
Determine conditions and values
Determine maximum number of rules
Determine actions
Encode possible rules
Encode the appropriate actions for each rule
Verify the policy
Simplify the rules (reduce if possible the number of columns)

11. Decision Tables - Usage
The use of the decision-table model is applicable when :
the specification is given or can be converted to a decision table .
the order in which the predicates are evaluated does not affect the interpretation of the rules or resulting action.
the order of rule evaluation has no effect on resulting action .
once a rule is satisfied and the action selected, no other rule need be examined.
the order of executing actions in a satisfied rule is of no consequence.
The restrictions do not in reality eliminate many potential applications.
In most applications, the order in which the predicates are evaluated is immaterial.
Some specific ordering may be more efficient than some other but in general the ordering is not inherent in the program's logic.

12. Decision Tables - Issues
Before using the tables, ensure:
rules must be complete
every combination of predicate truth values plus default cases are explicit in the decision table
rules must be consistent
every combination of predicate truth values results in only one action or set of actions

13. Test Case Design
Once the specification has been verified, the objective is to demonstrate that the implementation provides the correct action for all combinations of predicate values :
if there are k rules over n binary predicates, then there are at least k cases and at most 2n cases to consider.
Base test design on unexpanded rules or on the expanded rules with 2n tests
find the input vector to force each case.

14. Test Case Design
To identify test cases with decision tables, we interpret conditions as inputs, and actions as outputs.
Sometimes conditions end up referring to equivalence classes of inputs, and actions refer to major functional processing portions of the item being tested.
The rules are then interpreted as test cases.

15. Decision Table for the Triangle Problem
Conditions
C1: a < b+c? F T
C2: b < a+c? -
C3: c < a+b?
C4: a=b?
C5: a=c?
C6: b-c?
Actions
A1: Not a Triangle X
A2: Scalene
A3: Isosceles
A4: Equilateral
A5: Impossible

16. Test Cases for the Triangle Problem
Case ID a b c
Expected Output
DT1 4 1 2
Not a Triangle
DT2
DT3
DT4 5
Equilateral
DT5 ?
Impossible
DT6
DT7 3
Isosceles
DT8
DT9
DT10
DT11
Scalene

17. Decision Table for NextDate (First Attempt)
Let us consider the following equivalence classes:
M1= {month | month has 30 days}
M2= {month | month has 31 days}
M3= {month | month is February}
D1= {day | 1 ≤ day ≤ 28}
D2= {day | day = 29}
D3= {day | day = 30}
D4= {day | day=31}
Y1= {year | year = 1900}
Y2= {year | 1812 ≤ year ≤ 2012 AND year ≠ 1900 AND (year = 0 mod 4}
Y3= {year | 1812 ≤ year ≤ 2012 AND year ≠ 0 mod 4}

18. Decision Table for NextDate (1)
Conditions
C1: month in M1 M2
C2: day in D1 D2 D3 D4
C3: year in -
Rule count 3
Actions
A1: Impossible X
A2: Increment day
A3: Reset day
A4: Increment month ?
A5: reset month
A6: Increment year

19. Decision Table for NextDate (2)
Conditions
C1: month in M3
C2: day in D1 D2 D3
C3: year in Y1 Y2 Y3 -
Rule count 1 3
Actions
A1: Impossible X
A2: Increment day
A3: Reset day
A4: Increment month
A5: reset month
A6: Increment year

20. Decision Table for NextDate (Second Attempt)
Let us consider the following equivalence classes:
M1= {month | month has 30 days}
M2= {month | month has 31 days}
M3= {month | month is December}
M4= {month | month is February}
D1= {day | 1 ≤ day ≤ 27}
D2= {day | day = 28}
D3= {day | day = 29}
D4= {day | day = 30}
D5= {day | day=31}
Y1= {year | year is a leap year}
Y2= {year | year is a common year}

21. Decision Table for NextDate (1)
Conditions
C1: month in M1 M2
C2: day in D1 D2 D3 D4 D5
C3: year in -
Actions
A1: Impossible X
A2: Increment day
A3: Reset day
A4: Increment month
A5: reset month
A6: Increment year

22. Decision Table for NextDate (2)
Conditions
C1: month in M3 M4
C2: day in D1 D2 D3 D4 D5
C3: year in - Y1 Y2
Actions
A1: Impossible X
A2: Increment day
A3: Reset day
A4: Increment month
A5: reset month
A6: Increment year

23. Guidelines and Observations
Decision Table testing is most appropriate for programs where
there is a lot of decision making
there are important logical relationships among input variables
There are calculations involving subsets of input variables
There are cause and effect relationships between input and output
There is complex computation logic (high cyclomatic complexity)
Decision tables do not scale up very well
Decision tables can be iteratively refined