decision table is a good way to deal with combinations of things (e.g. inputs).
This technique is sometimes also referred to as a ‘cause-effect‘ table. The
reason for this is that there is an associated logic diagramming technique
called ‘cause-effect graphing‘ which was sometimes used to help derive the
tables provide a systematic way of stating complex business rules, which is
useful for developers as well as for testers.
tables can be used in test design whether or not they are used in
specifications, as they help testers explore the effects of combinations of
different inputs and other software states that must correctly implement
the developers to do a better job can also lead to better relationships with
them. Testing combinations can be a challenge, as the number of combinations
can often be huge. Testing all combinations may be impractical if not
impossible. We have to be satisfied with testing just a small subset of
combinations but making the choice of which combinations to test and which to
is also important. If you do not have a systematic way of selecting
combinations, an arbitrary subset will be used and this may well result in an
ineffective test effort.
condition relevant to decision
that result from a given set of conditions
which actions are to be followed for a given set of conditions
and structured presentation
errors is easier
incompleteness and inconsistency
related rules into single table
tables to achieve decision
Identify Conditions & Values:
data attribute each condition tests and all of the attribute's values.
Identify Possible Actions:
each independent action to be taken for the decision or policy.
Compute Max Number of Rules:
the number of values for each condition data attribute by each other.
Enter All Possible Rules:
the values of the condition data attributes in each numbered rule column.
Define Actions for each Rule:
rule, mark the appropriate actions with an X in the decision table.
Verify the Policy Review completed decision table
Simplify the Table Eliminate and/or consolidate
rules to reduce the number of columns.
Conditions Rule 1 Rule 2 Rule
3 Rule 4
amount has been entered:
loan has been Entered:
will identify all of the combinations of True and False. With two conditions,
each of which can be true or false, we will have four combinations (two to the
power of the number of things to be combined). Note that if we have three
things to combine, we will have eight combinations, with four things, there are
16, etc. This is why it is good to tackle small sets of combinations at a time.
In order to keep track of which combinations we have, we will alternate True
and False on the bottom row, put two True‘s and then two Falses on the row
above the bottom row, etc., so the top row will have all True‘s and then all
Falses (and this principle applies to all such tables).
next step we will now identify the correct outcome for each combination. In
this example, we can enter one or both of the two fields. Each combination is
sometimes referred to as a rule.
Decision table with combinations and outcomes:
point, we may realize that we hadn‘t thought about what happens if the customer
doesn‘t enter anything in either of the two fields. The table has highlighted a
combination that was not mentioned in the specification for this example. We
could assume that this combination should result in an error message, so we
need to add another action. This highlights the strength of this technique to
discover omissions and ambiguities in specifications. It is not unusual for
some combinations to be omitted from specifications; therefore this is also a
valuable technique to use when reviewing the test basis.
Decision table with additional outcomes:
make slight change in this example, so that the customer is not allowed to
enter both repayment and term. Now the outcome of our table will change,
because there should also be an error message if both are entered.
notice now that there is only one ‗Yes‘ in each column, i.e. our actions are
mutually exclusive – only one action occurs for each combination of conditions.
We could represent this in a different way by listing the actions in the cell
of one row. Note that if more than one action results from any of the
combinations, then it would be better to show them as separate rows rather than
combining them into one row.