A decision table is a good way to deal with different combination inputs with their associated outputs and also called cause-effect table. Reason to call cause-effect table is an associated logical diagramming technique called ’cause-effect graphing that is basically use to derive the decision table.
Decision table testing is black box test design technique to determine the test scenarios for complex business logic.
We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific conditions or inputs. Although, if we have dissimilar inputs that result in different actions being taken or secondly we have a business rule to test that there are different combination of inputs which result in different actions. We use decision table to test these kinds of rules or logic.
Why Decision table is important?
Decision tables are very much helpful in test design technique – it helps testers to search the effects of combinations of different inputs and other software states that must correctly implement business rules. Also, provides a regular way of stating complex business rules, that’s helpful for developers as well as for testers. Testing combinations can be a challenge, as the number of combinations can often be huge. It assists in development process with developer to do a better job. Testing with all combination might be unrealistic or unfeasible. We have to be happy with testing just a small subset of combinations but making the option of which combinations to test and which to leave out is also significant. If you do not have a efficient way of selecting combinations, an arbitrary subset will be used and this may well result in an ineffective test effort.
A decision table is basically an outstanding technique used in both testing and requirements management. It is a structured exercise to prepare requirements when dealing with complex business rules. Also, used in model complicated logic.
Way to use decision tables in test designing
Firstly; get to know a suitable function or subsystem that acts according to a combination of inputs or events. Taken system should be with fewer inputs or else combinations will become impossible. Always better to take maximum numbers of conditions, split them into subsets and use these subsets one at a time. After getting features that need to be combined, add them to a table showing all combinations of “Yes” and “No” for each of the feature.
Let’s take an example of a finance application, where users pay money – monthly Repayment or year wise (the term of loan). If user chooses both options, the system will create a negotiation between two. So, there are two conditions of the loan amount, mention in the given below table,
TABLE 1: Blank decision table
Conditions |
Step 1 |
Step 2 |
Step 3 |
Step 4 |
Repayment money has |
|
|
|
|
Terms of loan has been mentioned |
|
|
|
|
Next, recognize all of the combinations in “Yes” and “No” (In Table 2). In each column of two conditions mention “Yes” or “No”, user will get here four combinations (two to the power of the number of things to be combined). Note, if user has three things to combine, they will have eight combinations, with four things, there are 16, etc. Because of this, it’s always good to take small sets of combinations at once. To keep track on combinations, give alternate “Yes” and “No” on the bottom row, put two “Yes” and then two “No” on the row above the bottom row, etc., so the top row will have all “Yes” and then all “No” (Apply the same principle to all such tables).
TABLE 2: Decision table – Input combination
Conditions |
Step 1 |
Step 2 |
Step 3 |
Step 4 |
Repayment money has |
Y |
Y |
N |
N |
Terms of loan has been mentioned |
Y |
N |
Y |
N |
In the next step, recognize the exact outcome for each combination (In Table 3). In this example, user can enter one or both of the two fields. Each combination is sometimes referred to as a step.
TABLE 3: Decision table – Combinations and outcomes
Conditions |
Step 1 |
Step 2 |
Step 3 |
Step 4 |
Repayment money has |
Y |
Y |
N |
N |
Terms of loan has been mentioned |
Y |
N |
Y |
N |
Actions/Outcomes |
|
|||
Process loan money |
Y |
Y |
|
|
Process term |
Y |
|
Y |
|
At this time you didn’t think that what will happen when customer don’t enter anything in either of the two fields. The table has shown a combination that was not given in the specification for this example. This combination can result as an error message, so it is necessary to add another action (In Table 4). This will flash the strength this method to find out omissions and ambiguities in specifications.
TABLE 4: Decision table – Additional outcomes
Conditions |
Step 1 |
Step 2 |
Step 3 |
Step 4 |
Repayment money has |
Y |
Y |
N |
N |
Terms of loan has been mentioned |
Y |
N |
Y |
N |
Actions/Outcomes |
|
|||
Process loan money |
Y |
Y |
|
|
Process term |
Y |
|
Y |
|
Error message |
|
|
|
Y |
We will provide you some other example that allows the customer to enter both repayment and term. This will change the outcome of our table, this will generate an error message if both are entered (Shown in Table 5).
TABLE 5: Decision table – Changed outcomes
Conditions |
Step 1 |
Step 2 |
Step 3 |
Step 4 |
Repayment money has |
Y |
Y |
N |
N |
Terms of loan has been mentioned |
Y |
N |
Y |
N |
Actions/Outcomes |
|
|||
Process loan money |
|
Y |
|
|
Process term |
|
|
Y |
|
Error message |
Y |
|
|
Y |
The final process of this method is to write test cases to use each of the four steps in our table.
Advantage of decision table technique:
- Any complex business flow can be easily converted into the test scenarios & test cases using this technique.
- Such type of table are work iteratively, means the table created at the first iteration is used as input table for next tables. Such iteration can be carried out only if the initial table is unsatisfactory.
- Simple to understand and everyone can use this method design the test scenarios & test cases.
- It provide complete coverage of test cases which help to reduce the rework on writing test scenarios & test cases.
- These tables guarantee that we consider every possible combination of condition values. This is known as its “completeness property”.
Other test cases design techniques in Software testing:
Following black box testing techniques are used for testing the software application.
- Boundary Value Analysis (BVA)
Boundary Value Analysis is the most commonly used test case design method for black box testing. As all we know the most of errors occurs at boundary of the input values. This is one of the techniques used to find the error in the boundaries of input values rather than the center of the input value range.
- Equivalence Class Partitioning
The equivalence class partition is the black box test case design technique used for writing test cases. This approach is use to reduce huge set of possible inputs to small but equally effective inputs. This is done by dividing inputs into the classes and gets one value from each class. Such method is used when exhaustive testing is most wanted & to avoid the redundancy of inputs.
- State transition testing
The equivalence class partition is the black box test case design technique used for writing test cases. In this techniques the design the test cases for the system which describes the finite number of states. The state transition from one to other is based on the state of machine and depending upon the what happened before the output is varies for same inputs.
- Cause-Effect Graphing Technique
The Cause-Effect Graphing Technique is a black box testing technique which captures the relationships between specific combinations of inputs(causes) and outputs (effects). It deals with specific cases & avoids the combinatorial explosions. The graph includes a number of intermediate nodes linking causes and effects. Each Causes/effects are represented as nodes of a cause effect graph.
- Error Guessing
This is totally based on previous experience and judgment of tester. Good tester are encouraged to think conditions in which software may get the highest chances of getting errors. Such techniques do not have any rules to decide & totally based on experience.
About the author: Venktesh Somapalli is a Testing Lead professional with more than 7 years of work experience in testing industry. Over his testing carrier he used decision table technique for writing test scenarios & test cases for complex logic. He is currently working in Cognizant Technologies, Pune.
In this we have seen the how decision table testing technique is used. Have you used this testing techniques in your project. Please share your experience below in the comments section.
- Difference between Test Plan and Test Strategy
- Software Test Estimation – 10 Tips On How To Estimate More Accurately
- Boundary Value Analysis and Equivalence Class Partitioning With Simple Example
- Step by Step guide to Test Case Development
- Risk Based Testing – Statistical Model Testing Approach
- Creating, Configuring And Using A Board In Jira
- Do We Need Both Equivalence Partitioning And Boundary Value Analysis?
- Tutorial 6: Android application automation with TestComplete
- Handling IFrames in Selenium – Selenium Tutorial
- Why Can Codeless Testing Tools Overcome the Barriers of Test Automation in 2020?