Decision Table Testing is a Black Box test design technique (behavioral or behavior-based technique), used where different combinations of test input conditions result in different outcomes.When a system has complex business rules, then the decision table testing technique helps in identifying the correct test cases. As a result, it helps us to validate if the application/system can handle all the possible combinations of input data. The Decision Tables consists of CONDITIONS and ACTIONS which are also termed as INPUTS and OUTPUTS of a system. The representation of Conditions and actions will  be in the form of Table.

Usually, we represent the decision rules as True/False or discrete values or numbers or range of numbers. The decision table or Cause-Effect Table is a technique, generally applied when the requirements/business rules are in the form of tables OR flow charts. The main and the most important objective of Decision table testing is to ensure the overall test coverage without missing any possible relation. However, while creating the decision table coverage, it is essential to consider if there exists any boundary values check.

In such cases, Equivalence Class and Boundary value analysis also play a vital role as a complementary to Decision Table.

COLLAPSED DECISION TABLE TESTING:

When we try to validate the system with all possible combinations of data, the table becomes vast. Validating with huge data is a very time-consuming factor and also sometimes become impossible to test. Hence, the tester should follow specific rules to reduce the test data without affecting the test coverage intelligently.

Once a decision table is made with all the combinations of condition and actions, the table is shrunk by deleting the following columns:

  1. Impossible combinations of actions and conditions

  2. Possible, but infeasible combinations

  3. Combinations that do not affect the outcome

The minimum coverage for a decision table is at least one test case per a decision rule.

Coverage % = The number of decision rules tested by at least one test case / The total number of decision rules.

Example:


Consider a ‘Login’ Page Functionality.

Here are the business rules.

  1. On entering correct combination of ID & Password, user should be able to login successfully.

  2. User is not allowed to login when any or both of the ID & Password are incorrect /blank. In such cases, it should show ‘Invalid Credentials’ message.

We created the following combinations of Conditions, Actions and the respective rules in the decision table.

In the above table, there are

2 conditions – UserID, Password

2 Actions – Login Successfully, Error showing ‘Invalid Credentials’ and

3 Options — Blank, Valid, Invalid.

So, the total number of test cases are as follows:

You can collapse the above decision table based on certain rules as above.

So, let us try to reduce the number of test cases.

  1. Rules 1,2, 3, 4, and 5 cover the same action Item “Invalid Credentials” with options Blank and Invalid. Hence, we can consider any one of these test cases TC01 OR TC02 OR TC03 OR TC04 OR TC05

  2. Rules 6,7, and 8 cover the same action Item “Invalid Credentials” with options Valid and Invalid. Hence, we can consider any of these test cases TC06 OR TC07 OR TC08

  3. Rule 9 covers the action item “Login Successfully” with all valid options. Hence, we should consider the test case TC09.

Finally, we will collapse the Decision Table as shown below:

Advantages of Decision Table Testing:

  • Helps to identify all the important combinations of conditions. Otherwise, we may overlook.

  • Identification of any gaps in the requirements is possible.

  • It is useful at any test level where the software behavior depends on a multiple combinations of conditions. 

  • Conversion of complex business rules into simple decisions tables which the business users, testers and developers may use.

Limitations:

  • The decision table test case design technique is challenging when there are no requirements or no well-designed requirements.

  • The tables becomes more complex as the number of input values increase.

Sample Question from ISTQB:

Question:

One of the most important test goals for your project is to have 100% decision coverage. Therefore, we have to execute the following three tests for the control flow graph shown below. 

Test01 covers path: A, B, D, E, G

Test02 covers path: A, B, D, E, F, G 

Test03 covers path: A, C, F, C, F, C, F, G

Which of the following statements relating to the decision coverage goal is TRUE?

Answer Set:


  1. Decision D has not been tested completely. 

  2. 100% decision coverage has been achieved. 

  3. Decision E has not been tested completely. 

  4. Decision F has not been tested completely.

Explanation:

In the diagram ,there are following four conditions/decisions: A, D, E, F 

The Test_01 covers A->B, D->E and E->G

Test_02 covers A->B, D->E, E->F and F->G

The Test_03 covers A->C, F->C and F->G. 

Hence coverage in case of condition A is complete (A->B by Test_01 and A->C by Test_03),

condition E is covered (E->G by Test_01 and E->F by Test_02), 

Covered condition-F (F->C by Test_03 and F->G by Test_02 and Test_03). 

The no coverage of Condition D, there is only D->E by Test_01 and Test_02, but D->F is not covered. 

Hence 1) TRUE: D was not covered (see above) 

2) FALSE: 1 of 4 decisions was not covered (see above). So, there is only 75% decision coverage.

3) FALSE: E has been fully tested/covered (see above). 

4) FALSE: F has been fully tested/covered (see above)