3 Decision Table Examples and Use Cases
Many companies use business rules to specify the design of rules they’re looking to develop and implement. However, more complex logic requires that organizations create quality business rules from the outset. That way, they avoid running into issues that could complicate their efforts to boost organizational efficiency. Decision tables help by allowing business users to model complex business scenarios in an easily understood format.
Decision tables are structural representations of conditional logic used to define business rules. Each table contains a list of tasks outlining different conditions. They highlight what causes a rule to trigger, the action to take, and the effect of that decision. Software testers use decision tables to determine the reactions to expect from a system based on various input combinations.
By designing an input table, you can figure out how different inputs result in various outputs. For that reason, decision tables are also called cause-effect tables. In addition, decision tables aid in test design by helping testers figure out different combinations of inputs and software states that use business rules.
Using decision tables gives you a consistent way of laying out complicated business rules. That helps developers understand how a system should function and aids testers in making sure that the application conforms to the requirements provided by business users.
Other benefits of using decision tables include:
Decision tables work best for complicated scenarios. For example, they’re suitable for use with a system that demonstrates different behavior depending on the input. In addition, they allow us to thoroughly assess the potential outcomes for various decisions.
There are some decision table problems you should watch for. When you have a lot of different inputs, you’re going to end up with a larger and more unwieldy table. In addition, a decision table is not the same as creating a step-by-step guide on how to conduct tests. If you need those kinds of details, you’re better off writing out a full-on test case.
Decision tables can be of benefit to both testers and developers. A good rule of thumb is to lay out decision tables at the start of the system or software design phase.
Pull out the conditions and start creating your first column. Write out the conditions and actions in a list to get a True or False outcome. For example, if you were making a decision table for an ATM withdrawal, the conditions might line up like this:
Current Account Balance >= Withdrawal Request
We outlined that the business rule should check to verify that the amount requested by the user is less than or equal to the balance in their account. If the condition is true, the following action should be to provide the requestor with their desired withdrawal amount.
Figure out how many columns you’ll need in your decision table. That will vary depending on the number of conditions in your requirements and the different alternatives available. For example, if you have two conditions, and each can have a true or false outcome, then you’ll need four columns total.
1 condition = 2 columns
2 conditions = 4 columns
3 conditions = 8 columns
As you can see, you’ll end up doubling the number of columns you need for each additional condition. Ideally, it’s better to have a lot of small decision tables instead of a couple of big ones. That way, you avoid having your decision table too large to manage.
Once you have your table in place, find ways to remove columns that do not affect the outcome. That helps you eliminate redundancies. Next, get rid of any combinations that appear invalid or those that can’t happen because of an internal conflict. Use an x or – symbol to indicate the removal of the column. Finally, get rid of any duplicate columns.
Once you’ve got your decision table into the correct format, start thinking of the actions that would result from each column. Give each column a name or identifier that represents your business rule.
Map out the decisions on how an interface should respond when a user attempts to log in. For example, you can create a rule that the screen should display an error if the user enters a username without a password or incorrect ID/password combination. On the other hand, if the user provides the correct input, your rule can define how the system should allow access to the system or application.
You can outline the criteria that the system should evaluate when deciding whether or not to provide a loan or other credit to an applicant. For example, your table could check the credit score and income listed on the application. If one or both do not meet the minimum requirements to receive credit, you can outline an action that rejects the application. If it does, you can add an action that moves the application to a human reviewer to make a final decision.
Many companies outline a specific period during which customers can initiate a return. You can use decision tables to outline business rules for return requests. If a customer submits a request outside of the return period, then you can design an action that rejects the request. Otherwise, you can allow the request to move on to other rules to determine if it meets the criteria for receiving a refund.
Companies in different industries use Integrify to create workflows that help them manage business processes more effectively. Learn more about how Integrify can help your employees become more productive by scheduling a demo of our software.
Copyright © 2022 Integrify All rights reserved.