ISTQB definition:
Decision table testing - a black-box test technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table.
Human language:
Decision Table Testing - is a black box test design testing technique that examines how a system responds to various input combinations.
The Decision Tables consist of CONDITIONS and ACTIONS, which are also termed as inputs and outputs of a system. This is a systematic approach also called Cause-Effect Table, where the different input combinations and their corresponding system behavior with rules and conditions are captured in a tabular form.
When a system has complex business rules and logic, then the decision table testing technique helps in identifying the correct test cases. The main and most important objective of Decision table testing is to ensure the overall test coverage without missing any possible relation.
How does it work?
The first task is to identify a suitable function or subsystem that has a behavior that reacts according to a combination of inputs. The decision table technique is appropriate for functions that have a logical relationship between two and more than two inputs. After we have decided on the functions that are our conditions and put them into the table, we represent the decision rule for each condition.
Usually, we represent the decision rules as True/False or discrete values or numbers or range of numbers. Next, we will identify all the combinations of True and False based on our conditions. The minimum coverage for a decision table is at least one test case per a decision rule.
With two conditions, each of which can be True or False, we will have four combinations. If we have three things to combine, we will have eight combinations, with four things, there are 16, etc. This is why it is good to tackle small sets of combinations at a time or to divide a large number of conditions into subsets and deal with the subsets one at a time
Different combinations of conditions lead to different actions, therefore in the decision table, our goal is to identify the correct outcome for each combination and put them as actions that we expect for each combination of our conditions.
The result of the action might be displayed as Yes/No or Passed/Failed, depending on a rule for a condition.
The main advantage of Decision Table Testing is the possibility to identify all the important combinations of conditions, and it aids the systematic selection of effective test cases and can have the beneficial side effect of finding problems and ambiguities in the specification. However, the decision table test case design technique is challenging when there are no requirements or no well-designed requirements.
Life example:
Let's take a look at the example of how to use the decision table in real cases.
Example: Decision table for authorization form
Imagine that our development team builds the login form for any website.
Requirements for our login form are:
The login form consists of:
Email field;
Password field;
Sign In button.
Validation for our fields:
After inputting an invalid email or password, the error message displays: 'Invalid email or password. Please re-enter your user information and try again'.
So, the team of developers is developing this login form based on our requirements. The next step is to test it. For that reason, we have to write test cases, which will cover all possible scenarios of input data for our login form, and the best way to do that is to use a decision table.
As you remember, the Decision Tables consist of CONDITIONS and ACTIONS, which are also termed as inputs and outputs of a system.
Our first step is to define all the conditions and actions for our Login form. Due to we have only two fields with the possibility to input different combinations of inputs, our decision table will consist of 2 conditions:
Email;
and Password.
These two fields lead to one action - Authorization, so we put this field in the actions row of the decision table:
Our next task is to identify all the combinations of True and False based on our conditions.
Each of our fields might be empty, with valid data and with invalid data.
This means that we will have 9 combinations with different input data, i.e. test cases, which we write in the table as rules:
Each of these rules leads to action, and after running all of these combinations, we receive the next results:
As you can see, only test case 9 should be successful, and it is a positive test case, the other test cases are negative, and should lead to an error, which is displayed in our requirements.
Thus, with the help of the decision table, we have covered all possible data entry scenarios, both positive and negative.
Conclusion:
So, if you are asked at an interview: What is Decision Table testing? The best way to answer is:
Decision Table Testing - is a black box test design testing technique that examines how a system responds to various input combinations.
The Decision Tables consist of CONDITIONS and ACTIONS, which are also termed as inputs and outputs of a system. This is a systematic approach also called Cause-Effect Table, where the different input combinations and their corresponding system behavior with rules and conditions are captured in a tabular form.
The main and most important objective of Decision table testing is to ensure the overall test coverage without missing any possible relation.