Concept: test the rules that govern handling of transactional situations
Model: table (or Boolean graph) connecting conditions with actions
Test derivation: fulfill conditions, check actions
Coverage criteria: at least one test per combination of conditions (DT column)
Bug hypothesis: improper action or missing action
Example: Deriving Tests
In the example just shown, each column of the table is a testcase
We will create the conditions (which are the test’s inputs)
We will verify the actions (which are the test’s expected results)
In some cases, we might generate more than one test case per column (more later)
In this case, some of the test cases don’t make much sense; e.g.:
Account not real but account active?
Account not real but account within limit?
Maybe we don’t need all the columns in our decision table?
Collapsing a Decision Table
If the value of one or more particular conditions can’t affect the actions for
two or more combinations of conditions, we can collapse the decision table
This involves combining two or more columns
Combinable columns often but not always next to each other
Look for two or more columns that result in the same combination of
actions (for all the actions in the table)
Replace the conditions that are different in those columns with “-” (for
don’t care/doesn’t matter/can’t happen)
Repeat this process until no further columns share the same combination
of actions or where collapse would erase an important distinction
Be careful with tables that have non-exclusive rules
