The decision table is a test case design technique. It’s a table that visually represents all possible combinations of input values and their corresponding output values for the system under test (SUT). Decision tables are also known as “truth tables” or “decision trees”.
Decision tables can be used to define business rules for new system implementations. Used properly, they allow us to reduce risk related to system change and provide a clear, simple way to communicate the definition of our business rules.
Introduce Decision Tables
Decision tables are very useful when writing test cases for complex software systems and web applications that have a lot of requirements or business rules that must be exercised by the system under test (SUT). It allows us to specify each combination of input values and expected actions in a structured format which makes them easy for anyone to understand without having any prior knowledge of your application.
However, decision tables may not work well if we have too much data from one column or don’t want to maintain them after they have been created; therefore, there should be some debate before attempting out whether they are the appropriate choice for your testing needs.
What is a decision table?
Decision tables can be used for test design as well as requirements and specification purposes. By using decision tables we can clearly list all possible combinations of input values and their corresponding output values for the SUTs (system under test).
Decision tables can be used as a test design tool, but they need to be used with care. Let’s look at some guidelines for using decision tables:
- Decision tables are not suitable for data-driven testing techniques such as boundary value analysis or equivalence partitioning.
- Don’t extend a decision table arbitrarily. If you find yourself in an uncontrolled situation, use parameters to structure the development of corresponding test cases rather than extending the decision table ad infinitum.
- Remove ambiguity. Decision tables must be unambiguous and complete. They should not have any missing lines or conclusions. Each input value must have a corresponding conclusion in the appropriate line of the decision table.
- Make it easy to use by using parameters instead of literals and variables whenever possible.
Why Decision Table Testing is Important?
A very common question that arises among testers is, why do I need to use decision tables? Well, the answer lies in making sure we have clear requirements and specifications for our system under test (SUT).
Using decision table testing gives us a way to describe the SUT and its behavior using a structure that can be easily understood by all stakeholders. This structured approach allows us to walk through each line of the chart with ease while fulfilling test cases to ensure all possible combinations of input values exist. By doing this we are able to validate both positive and negative results from the SUT.
Because there will always be additional input values beyond those listed in the decision table, it is important not only to test the expected positive and negative values but also combinations of each input value.
Creating Good Decision Tables
The following are some guidelines to follow whenever using decision tables:
- Include as few columns as possible while covering all of the statements under test. If there is too much information in one column, consider breaking it up into multiple columns.
- Don’t use a generic verb for any column headings; instead, replace them with precise actions from the system’s documentation or user interface specification.
- Specify the order in which you are testing each variable. This not only helps to maintain consistency in your testing but also makes it easier to reference each variable by number rather than name.
- When generating positive and negative results, consider using “(unknown)” rather than leaving a cell blank to represent invalid data values that may be received by the system under test.
- Clearly label each input value as either positive, negative, or unknown. This will help the reader to understand the system’s behavior such as when the positive result of user name “John” is received and it contains an incomplete address.
Advantages of Decision Table Testing
- Specify the SUT, its actions, and all possible combinations of input values in a structured format.
- Make certain the SUT is behaving as specified by increasing test coverage and guaranteeing that positive and negative results are tested.
- Help reduce testing time for complex systems; this can be done by reducing developer errors due to missed requirements or misunderstood specifications.
Disadvantages of Decision Table Testing
When using decision tables there are several concerns that need to be addressed: – The effort required to create them may increase the overall cost of developing automated tests. However, this cost is usually justified because it will likely save money throughout the testing process.
- Decision tables must be updated at the same time as any change to the SUT’s specification or user interface.
- The larger the table, the longer it will take to create and maintain it. Unless we are using decision tables in an automated fashion this can prove challenging because if each row is generated manually then there is a greater chance of error than if they were generated automatically (i.e., using Python scripts).
- If test cases are not properly executed, missing results may occur adding even more variables into the mix that need to be tested; this could make decision tables difficult to maintain and increase testing costs without realizing increased coverage.
Decision Table Example
Make a Decision Base Table for the Login Screen
TIP: When developing test cases that verify all combinations of positive and negative results make sure to also include “unknown” as a value because it is possible to receive data that causes invalid actions; therefore, there should always be at least one row with “(unknown)” for every variable. This will help ensure all combinations are tested by having your automated scripts generate them using rules based on the decision table. For more information on this please refer to my previous post: Rule-Based Automated Testing.
Decision table testing is a form of boundary value testing that uses structured techniques to specify, design, and test input/output combinations. This includes both positive (expected) results and negative (unexpected) results because it helps ensure all value ranges are correctly tested not just those which cause errors.
Have you ever used decision table testing? If so then please share your experiences below in the comments section.