Decision tables and their use in testing

Decision tables are used to study the interaction between combinations of conditions. They provide a clear method for testing all relevant combinations to guarantee that the product processes all possible conditions, relationships, and constraints. Decision tables are an effective software testing method used to analyze how a system responds to various input data.

Decision table testing is one of the black box test design techniques that is part of dynamic analysis. It is also known as a cause-and-effect table. And the schematic demonstration of the logic is known as a cause-and-effect graph. This visual representation is used to generate a decision table.

Other methods of investigation, for example, equivalence testing or limit value analysis, often apply only to specific inputs. The decision table technique is used in the case where a combination of inputs is applied to different outputs. The main goal is to check the business logic and test coverage.

The decision table, as a rule, has 4 components:

1. Conditions – the list of possible conditions.
2. Action options are a combination of a list of fulfilled or unfulfilled conditions.
3. Actions – a list of all possible actions.
4. Action requirement – indicates whether or not the corresponding action is required for each of the condition combinations.

The example of decision table application.

The condition is pretty simple: if users enter a valid username and password, they will be authorized and redirected to the homepage. If any of the data are entered incorrectly the error message will appear.

Symbols:

T – Valid username/password

F – Invalid username/password

E – Display of the error message

H – The user is authorized/the homepage is opened

Let's look at each of the columns:

Column 1. The username and password were invalid. The error message is displayed.

Column 2. Username was valid but the password was invalid. The error message is displayed. 

Column 3. Valid username and password. The error message is displayed. 

Column 4. The username and password were valid. Authorisation is successful, the homepage is displayed.

To convert this into a test example you can create several test cases.

Test case 1. Enter a valid username and password, and click the «Login» button.

Expected result: The user is authorized and redirected to the homepage.

Test case 2. Enter a valid username and invalid password, and click the «Login» button.

Expected result: The error message is displayed.

Test case 3. Enter an invalid username and a valid password, and click the «Login» button. 

Expected result: The error message is displayed. 

Test case 4. Enter an invalid username and password, and click the «Login» button. 

Expected result: The error message is displayed. 

Pay attention to the fact that all cases except the first one check the same rule. Therefore, a simple decision table has been created. It also can be expanded if necessary.

Another example of using decisions on the instance of printer performance

Symbols: Y – yes; N – no.

This example demonstrates the simplicity with which the decision table shows possible combinations of conditions and actions. It can also be easily modified if the initial data changes (for example, if a different color indicator is turned on in the printer).

Advantages of using a decision table during software testing:

1. With this method, even the most complex business logic can be easily transformed into test scenarios and cases.
2. Work iteration. The table created at the first stage is used as input for the following. Iteration is performed only if the output data is not satisfactory.
3. Simple and intuitive technique. Anyone can use this method to develop test scenarios and cases.
4. Providing full coverage of test cases, which significantly reduces the amount of work.
5. Guarantee of all possible condition and value combinations.
6. Providing more compact documentation.
7. Easy data modification.

Disadvantages of decision tables in software testing.

1. Difficulties in scaling. You need to «split» large tables into smaller ones to prevent redundancy.
2. Increasing the input data makes the table more complex.

Decision tables are a good way to describe requirements when there are multiple business rules that interact with each other. Using this method, it will be easier for a specialist to write requirements that include all available conditions. This technique helps to better analyze the tested product and systematize all knowledge about it. As a result, it becomes easier to write complete test cases, to cover all possible combinations.