How To Test Complex Requirements Using Decision Tables

What is Decision Table Testing?

Decision table testing is a black-box test design technique that is used to determine the test scenarios for complex business logic, primarily involving various input combinations.

Why is Decision Table Important?

• It provides 100% decision coverage for features with complex and several business rules.
• By using this formal technique, complex business flow can be easily converted into the test scenarios & test cases without running into the risk of missing out on both evident and imperceptible situations.
• These tables guarantee that we consider every possible combination of condition values. This is known as its “completeness property.”

Requirement Analysis using UML diagram

Earlier, I worked on a project which initially had only one workflow with comparatively straightforward logic. Hence, there were fewer chances to miss any scenario. But as the project grew, the number of workflows increased by 1200%, and so did the logic per workflow. The first issue was to remember each workflow and multiple scenarios/logic for that workflow. We resolved this issue by using the UML Diagram which we used to create a flow diagram for our convenience to verify the status transition logic of an entity form based on the selection of its button and no. of days. The labels of the buttons were Marked as Closed and Raise Issues.

The initial status of the entity should be Pending Client Acknowledgement and on click of any of the buttons, and based on the number of days. The entity status should be changing to either to the Closed status or the Dispute status.

 Based on those conditions and the client's actions, we identified a few scenarios:

1. If the entity status is Pending Client Acknowledgement and no action is performed for more than three days, then it should be automatically closed by the system.
2. If the Client clicked the Marked as Closed button, then entity status should be changed to Closed.
3. If the Client is selecting the button Raise Issues, then the below steps need to follow to mark the entity as Closed.
   • On the selection of the button, it should open the Issues list screen. The screen should have a button to Add Issue.
   • On the selection of the Add Issue button, a form should open to adding issue detail.
   • On the submission of the issue form, entity status should change to Dispute state.
   • Manager can close the issues with below conditions:
     • If issues closed after three days, then the entity's status should be Closed.
     • If issues closed before three days, then the current status should be Pending Client Acknowledgment.

Refer below image to understand the above requirement using a UML diagram with a visual representation of various conditions and statements.

The UML diagram helps us to identify the high-level testing scenarios and to understand its functionality workflows visually. But, when there are multiple scenarios, then it becomes difficult to locate the sequence in which scenarios should be performed to complete the testing in less time and effectively. To resolve that, the Decision Table is a prominent method to identify all the possible scenarios, and also it helps to deal with different combinations of inputs with their associated outputs.

How to Create a Decision Table?

As explained above, Decision Table Testing is a way to deal with different combinations of inputs with their associated outputs. Before creating a decision Table, we need the following details:

1. Identify all input conditions and what could be the Result. 
2. Count total no. of input conditions
3. Next, calculate the total possible scenarios using below formulae:
   • Formulae for Decision Table Scenarios = 2^N( As a decision will always be in the form of choosing either Yes or No or either True or False or either A or B)
   • N is the total number of input combinations.
     • So, if you have total no. of 3 input conditions then total no. of scenarios will be 2³ = 2 * 2 * 2 = 8
4. Start adding input conditions in different combinations and identify and write output for each.

Now let’s understand how to create a decision table for the same requirement: 

1. First of all, we need to identify the input conditions and possible result:

• Input Conditions

  • Entity’s Current Status(Status before executing the input conditions)

    • Pending Client Acknowledgement

    • Dispute

  • No. of days

    • < = 3

    • >3

  • Action

    • Marked as Closed(by selecting the button ‘Marked as Closed’, Client can be Marked the entity as Closed)

    • Raise Issue(by selecting the button ‘Raise Issue’, Client can raise the issue)

    • Closed Issue(by resolving the Issue, Manager can resolve the issue)

• Output Conditions

  • Available Buttons

  • Entity’s Final Status(Status after executions of input conditions)

2. As per the above point, we will have a total of 3 input conditions.

3. Based on the input conditions we will have to perform 8 input combinations (2³ = 2 * 2 * 2 = 8)

4. Let’s start adding it in tabular form:

Here, if the entity status is Pending Client Acknowledgement, then the client can take actions, and if the status is Dispute, then the only manager can perform the actions.

Note:  ‘X’ = Don’t Care

Let’s understand each scenario in detail:

Scenario 1 

Status of Entity: Pending Client Acknowledgement 
No. of Days: <= 3
Action: None
In words: If the entity status is “Pending Client Acknowledgement”, and a user has not performed any action within three days. Then there is no change in the status of the entity and the buttons that are displayed on the entity form.

Scenario 2

Status of Entity: Pending Client Acknowledgement 
No. of Days: <= 3
Action: Mark entity as Close
In words: If the entity status is “Pending Client Acknowledgement” and a user clicks on “Mark as closed” action within three days. Then the entity status will be changed to close, and there won’t be any visible buttons on the entity form.

Scenario 3 

Status of Entity: Pending Client Acknowledgement 
No. of Days: > 3
Action: None
In words: If the entity status is “Pending Client Acknowledgement” and the user does not take any action for more than three days, For this case as well, the entity status will be changed to close, and there won’t be any visible buttons on the entity form.

Scenario 4

Status of Entity: Pending Client Acknowledgement 
No. of Days: <= 3
Action: Raised issue for the entity
In words: If the entity status is “Pending Client Acknowledgement” and the user does not take any action for more than three days, and the user clicks on action “Issue Raised”. The entity status will be changed to “Dispute” and a button ‘Raise Issues’ will be visible on the entity form. 

Scenario 5

Status of Entity: Dispute
No. of Days: Don’t care(<>=3)
Action: None
In words: If the entity status is “Dispute” for no matter how many days, and if no action is taken, then there will be only one button available with the label ‘Raise Issues’, and here the entity status remains unchanged i.e. Dispute. 

Scenario 6  

Status of Entity: Dispute
No. of Days: Don’t care(<>=3)
Action: Raised Issue

In words: If the entity status is “Dispute” for no matter how many days, and if the client raises an issue again. Then also there will be only one button available with the label ‘Raise Issues’, and here the entity status remains unchanged i.e. Dispute.

Scenario 7

Status of Entity: Dispute
No. of Days: <= 3
Action: Issue Closed
In words: In this scenario, entity status is a Dispute and if the manager closes all issues within three days, then entity status will be changed to Pending Client Acknowledgement and both buttons will be visible.

Scenario 8

Status of Entity: Dispute
No. of Days: >3
Action: Issue Closed
In words: In this scenario, entity status is a Dispute. If the manager closes all issues after three days, then entity status will be changed to closed, and there won’t be any visible buttons on the entity form.

Summary

• A decision table helps to depict all the decisions of a feature which sometimes may not be possible with a flowchart diagram.
• A decision table provides a framework for a complete and accurate statement of processing or decision logic. It helps the tester to cover all valid input combinations and test accordingly.
• A decision table is compact and easily understood making it very effective for communication between teams.