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 with many 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, making them easy for anyone to understand without 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, requirements, and specifications. Using decision tables, we can 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 must be used carefully. Let’s look at some guidelines for using decision tables:
- Decision tables are unsuitable for data-driven testing techniques such as boundary value analysis or equivalence partitioning.
- Don’t extend a decision table arbitrarily. If you are 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 using parameters instead of literals and variables easy to use whenever possible.
Why Decision Table Testing is Important?
A common question among testers is why I need to use decision tables. The answer is ensuring we have clear requirements and specifications for our system under test (SUT).
Using decision table testing allows us to describe the SUT and its behavior using a structure easily understood by all stakeholders. This structured approach allows us to walk through each line of the chart easily while fulfilling test cases to ensure all possible combinations of input values exist. By doing this, we can validate positive and negative results from the SUT.
Because there will always be additional input values beyond those listed in the decision table, testing the expected positive and negative values and combinations of each input value is important.
Creating Good Decision Tables
The following are some guidelines to follow whenever using decision tables:
- Include as few columns as possible while covering all the statements under test. Consider breaking it into multiple columns if too much information exists in one column.
- Don’t use a generic verb for column headings; 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 helps maintain consistency in your testing and 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 blank cell to represent invalid data values the system may receive 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 the 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.
- Ensure the SUT behaves 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
Several concerns must be addressed when using decision tables: 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 simultaneously with 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 use decision tables in an automated fashion, this can prove challenging because if each row is generated manually, 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 also to 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, please refer to my previous post, Rule-Based Automated Testing.
Conclusion
Decision table testing is a form of boundary value testing that uses structured techniques to specify, design, and test input/output combinations. This includes positive (expected) and negative (unexpected) results because it helps ensure all value ranges are correctly tested, not just those that cause errors.
Have you ever used decision table testing? If so, then please share your experiences below in the comments section.
