Decision table testing with example

In the previous blog post, we learned about two important test case design techniques such as Equivalence partitioning, and Boundary value analysis. These techniques are mainly used to test individual input conditions. However, decision table testing allows us to examine combinations of conditions.

Decision table testing is a black box design technique in which test cases are designed to execute the combinations of inputs defined in the decision table.

So what is a decision table?

       It is a table showing combinations of inputs and/or causes with their associated outputs and/or actions (effects), which can be used to design test cases.

This definition seems quite confusing.

Don’t worry.

Let’s examine some of the examples for decision table testing.

Consider the following sample business requirement:

A company’s employees are paid bonuses if they work more than a year in the company and achieve individually agreed targets.

Try to list out all the conditions and actions mentioned in the requirements. Hopefully, you would have listed out the conditions as listed below.


  • Employment for more than 1 year?
  • Agreed target?
  • Achieved target?

Actions / Outcome :

  • Bonus payment?

With all these details, let’s draw the decision table.

decision table

*decision table

In the given requirement, there are 3 different conditions. Each of these conditions has two options (YES/NO). Hence the total number of possible combinations is 8 (i.e. 23). 

If there are 6 conditions and each with 5 different options, then the total number of combinations will be 15,625 (i.e. 56).

How to identify test cases from decision table?

In a decision table, conditions consider as inputs and actions as outputs. Each rule can be interpreted as a test case. In this way, decision table testing ensures complete coverage.

However, in the above decision table, few rules wouldn’t occur in the real situation. Hmm.

Are you able to identify those rules on the table?

Can we collapse the decision table to remove unlikely combinations?

Look at Rules R5 and R6 in the table above. These rules are not making sense in the real world scenario (i.e. Achieving without agreeing on target). Hence this can be eliminated from testing.

Collapsed decision tables are a risk-based technique in which we reduce the full decision table and concentrate on the most likely and highest risk conditions and outcomes and remove combinations that are simply not possible.

This requires a very good understanding of business requirements in order to minimize the risk of eliminating something we actually need to test.

Prominent Use:

Decision table technique is predominantly used to test the if–then–else logic in programs. This technique is commonly applied to the integration, system and acceptance test levels.

Finding all the interacting conditions can be challenging, particularly when requirements are not well defined.

Typical defects found in decision table testing include incorrect processing based on particular combinations of conditions which results in unexpected results.

During the creation of the decision tables, defects may also be found in specification documents. The most common types of defects are

  • omissions (there is no information regarding what should actually happen in a certain situation) 
  • contradictions