ISTQB – What is Decision Table Testing in Software Testing

Decision Table Testing:

Consider this  from an vehicle insurance Functional Spec:

If the age of the driver is greater than 25 and the driver is female, offer a discount of 10%.

In Equivalence Partitioning and Boundary Value Analysis, the focus was on single or specific inputs and probably more focused on UI. And the techniques help in designing test cases for the individual fields – for example Age individually and Gender individually in the above example.

However, the combination also matters in the above example – i.e. Age and Gender together. There are 4 combinations that arise – Female driver aged 26(>25), Female driver aged 24 (<25), Male Driver aged 24(<25), Male driver aged 26(>25). The first is a positive test case with an expected result of 10% discount and the rest are  negative test cases with a discount of 0%.

Consider the following from another specification – For a Female driver aged >25, no accidents, SUV, with children – offer a 20% discount. Here the number of combinations comes to 16, withe 4 fields that can be evaluated as True or False.

When the number of decisions in a specification increases, it is difficult to keep track of all combinations.  The Decision Table technique comes in handy for such situations.

A Condition is an input field that can be evaluated as  True or False , eg: Age < 25 – True or False.  A decision is the expected result for a combination of conditions.  Specifications are full of business rules which are nothing but decisions based on a combination of inputs.  Individual conditions are usually simple to understand but the combinations can turn out to be complex.  And a decision table ensures every combination has been captured systematically.

A decision table lists all the input conditions that can occur and all the actions that can arise from them. These are structured into a table as rows, with the conditions at the top of the table and the possible actions at the bottom.

How to derive test cases and draw a DT:

• First step, identify the input conditions from the specification
• Next, identify the combinations of conditions that produce an outcome or Action.
• Identify the possible actions.
• Draw a table, in the first column, list the conditions one by one in each row, followed by the possible Actions.
• In the columns that follow, we evaluate each of the condition as True or False and the Actions that are appropriate for each combination of the condition are ticked.

Thus, each subsequent column is a Business Rule that and the Action that would arise. The strength of this technique lies in creating systematic combinations of conditions and expected results or Actions.

Let us look at a Car Rental Example:

The specification says: If Age is over 23 and the person has a Clean driving record, supply rental car, else reject.

There are 2 conditions: Age and Clean driving record
And 2 Actions: supply rental car, do not supply rental car
2 conditions = 4 rules.

We list the conditions in the first column, followed by the Actions.

 Conditions/Input Rule 1 Rule 2 Rule3 Rule4 Age > 23 Clean driving record Action/Output Supply rental car

Then, we start evaluating the conditions to be True or False and for the combinations that arise, the appropriate action.

 Conditions/Input Rule 1 Rule 2 Rule3 Rule4 Age > 23 T T F F Clean Driving record T F T F Action/Output Supply rental car Y N N N

With 2 conditions, there are 4 combinations (two to the power of the number of things to be combined), so if three conditions – the number of combinations is 8(2^3), and for 4 conditions, the number of combinations is 16 (2 ^ 4).

Decision Table technique is used after Equivalence Partitioning and Boundary Value Analysis have been applied.

This site uses Akismet to reduce spam. Learn how your comment data is processed.