Decision Table Testing A Complete Overview

In the software testing world, there is a saying “Exhaustive testing is a myth and is just not feasible”. And there are many different types of software testing techniques available each with its own strength and weakness. We need a more preferable testing technique based on the requirement and project, that can select test cases intelligently and make sure all test scenarios are covered.

Broadly, as per ISTQB, there are two main categories of software testing techniques present.

1. Static Testing Techniques: Testing of a component or system at specification or implementation level without execution of the software product, for example, different types of review, planning, kick-off meetings, preparation for work etc.

2. Dynamic Testing Techniques: Testing that involves the execution of the software product or the system.

Dynamic Testing techniques are again subdivided into three more categories:

i)           Specification-based Technique / Blackbox Testing Technique/ Behavioural Testing Technique

ii)          Structure-based Technique/ Whitebox Testing Technique/ Structural testing technique

iii)        Experience-based Testing Technique

The Specification-based testing technique is a procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional of a component or system without reference to its internal structure. In short, the tester is more concentrated on what the software does not how it does the work.

There are four specification based design techniques available:

1. Equivalence partitioning

2. Boundary value analysis

3. Decision table

4. State transition testing

The technique of Equivalence partitioning and Boundary value analysis is often more focused on the user interface, whereas Decision table and State transition testing are more focused on business logic or business rules.

What is Decision Table Testing?

“Decision Table Testing” is a black box test design technique in which test cases are designed to execute the combinations of inputs shown in a decision table. Decision table testing is a good way to deal with combinations of inputs.

What is a Decision table?

According to Wiki, “Decision tables” are a concise visual representation for specifying which actions to perform depending on given conditions or inputs. These are the algorithms whose output is a set of actions. These actions further can be used to design the test cases.

This table is sometimes also referred to as a “cause-effect” table. The reason for this is that there is an associated logic diagramming technique called as “cause-effect graphing” which was sometimes used to help derive the decision table.

Can This Technique be used during test automation?

As we saw, decision table testing is a technique to design test cases based on the combinations of inputs and outputs for a system or a component. It helps to cover all possible scenarios and helps us to reduce redundancy and complexity. However, creating and executing decision table tests manually can be time-consuming and error-prone. Hence, automating decision table testing can bring us several advantages, such as:

i)           Saving time and effort

ii)          Improving test coverage and hence the quality improves.

iii)        Enhancing maintainability and scalability, and facilitating communication and collaboration.

iv)         Generating test cases and executing them automatically eliminates human errors.

v)          Updating test cases becomes easy and reusing them for different scenarios makes the process more efficient.

That’s why you might want to automate decision table testing using some tools or techniques.

There are various tools available to help you automate the tests that you derive via decision tables, depending on your needs and preferences.

For instance, you can automate the inputs and expected outcome of the decision tables using Testsigma a unified cloud-based test automation tool that lets you automate the test cases just in simple English – no coding required.

Way to use Decision Table:

·   The first task to use decision tables is to identify a suitable function or subsystem that has a behaviour which reacts according to combinations of inputs or events.

·   For example, if we take a login screen of any application, it contains different inputs such as username, password, two-factor authentication etc. and has resulted in different action/outputs such as invalid password shouldn’t allow login, only authorized username and correct password should be able to login to the applications etc.

·   We also need to make sure there shouldn’t be too many inputs otherwise the number of combinations will become cumbersome and difficult to manage.

·   In case you have to deal with a large number of conditions it is recommended that you divide them into subsets and deal with the subsets one at a time.

·   Once you have identified the aspects that need to be combined, then you put them into a table listing all the combinations of True and False for each of the aspects.

In the following two examples, we will learn about how to apply decision table testing in different software projects.

Example 1: How to make Decision Base Table for Login Screen

Specification:

Let’s take the example of a login screen of say Testsigma application. The condition states that if the user provides the correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed on the screen.

Decision Table for login screen:

Conditions	Rule 1/TC1	Rule 2/TC2	Rule 3/TC3	Rule 4/TC4
Email Id (Input)	T	T	F	F
Password (Input)	T	F	T	F
Action(Output)	H	E	E	E

In the above example, the

T stands for correct Email id/password.

F stands for incorrect Email id/password

H stands for Home screen to be displayed to the user

E stands for the Error message to be displayed to the user

TC stands for the Test case.

Now let’s discuss the actions or output of the above decision table as per the provided inputs(email id and password).

Test Case 1 – The email id and password both are correct. Hence, the user should be directed to Testsigma’s Homepage.

Test Case 2 – The email id was correct, but the password was wrong. Hence, an error message should be shown to the user mentioning “Incorrect Password”.

Test Case 3 – The email id was wrong, but the password was correct. Hence, an error message should be shown to the user mentioning “Incorrect Email Id”.

Test Case 4 – The email id and password both are incorrect. Hence, an error message should be shown to the user mentioning “Incorrect Email Id”.

In the above example, you saw how all possible conditions or test cases have been included, the testing team can refer to this decision table and create their test cases so that upcoming bugs can be found at the testing level.

Let’s discuss another example of  how a decision table can be used in case of an upload screen:

Example 2: How to make Decision Table for Upload Screen

Let’s now take another example, we consider the decision table and test scenarios for an Upload screen.

There is a dialogue box that will ask the user to upload a file.

Specification:

The file should be in .png format.

The size of the file should be less than 25kb.

The file resolution must be 132*170px.

Now, let’s create a decision table for the upload screen keeping the above specification in mind: 

Decision Table for upload screen:

Conditions	Rule 1/TC1	Rule 2/TC2	Rule 3/TC3	Rule 4/TC4	Rule 1/TC5	Rule 2/TC6	Rule 3/TC7	Rule 4/TC8
Format (Input)	.png	.png	.png	.png	Not .png	Not.png	Not.png	Not.png
Size(Input)	<25kb	<25kb	>=25kb	>=25kb	<25kb	<25kb	>=25kb	>=25kb
Resolution(Input)	= 132*170px	!= 132*170px	=132*170px	!= 132*170px	=132*170px	!= 132*170px	=132*170px	!= 132*170px
Action(Output)	Upload the .png file successfully.	Error Message displaying resolution mismatched.	Error message displaying size mismatch	Error message displaying size mismatched	Error Message displaying format mismatched.	Error Message displaying format mismatched.	Error Message displaying format mismatched.	Error Message displaying format mismatched.

Based on the above decision table data, we can develop eight separate test cases to assure comprehensive coverage for the given specification.

Test Case 1: Click on upload to add a file with the format of ‘.png,’ type, with a file size of less than 25kb, and a resolution of 132*170 pixels. The expected outcome is that the photo will upload successfully.

Test Case 2: Click on upload to add a file with the format of ‘.png’ type, with a file size of less than 25kb, and a resolution of more than 132*170 pixels. The expected outcome is that it should display an error message text with the file resolution mismatch string and the user shouldn’t be able to upload the file.

Test Case 3: Click on upload to add a file with the format of ‘.png’ type, with a file size of more than 25kb, and a resolution of 132*170 pixels. The expected outcome is that it should display an error message text with the file size incorrect string and the user shouldn’t be able to upload the file.

Test Case 4: Click on upload to add a file with the format of ‘.png’ type, with a file size of more than 25kb, and a resolution of less than 132*170 pixels. The expected outcome is that it should display an error message text with the file size incorrect string and the user shouldn’t be able to upload the file.

Note: Even if the resolution is not equal to 132*170px, it should give a size incorrect error message as size would be the first validation and the size is wrong in this case.

Test Case 5: Click on upload and select a file with a format of other than ‘.png’ type, with a file size of less than 25kb, and a resolution of 132*170 pixels. The anticipated outcome is an error message should be displayed mentioning there is a format mismatch and the user shouldn’t be allowed to upload the file.

Test Case 6: Click on upload and select a file with a format other than ‘.png,’ type and a file size of less than 25kb, and a resolution of more than 137*177 pixels. The anticipated outcome is an error message should be displayed mentioning there is a format mismatch and the user shouldn’t be allowed to upload the file.

Note: Even if the resolution is not equal to 132*170px, it should give a format mismatch error based on the first format validation and it is incorrect.

Test Case 7: Click on upload to add a file in a format other than ‘.png’ type, with a file size equal to 25kb, and a resolution of 137*177 pixels. The expected outcome is an error message should be displayed mentioning there is a format mismatch and the user shouldn’t be allowed to upload the file.

Note: Even if the size is not less than 25kb, it should give a format mismatch error based on the first format validation and it is incorrect.

Test Case 8: Click on upload and select a file with a format other than ‘.png’ type with a file size of more than 25kb, and a resolution of less than 137*177 pixels. The expected outcome is an error message should be displayed mentioning there is a format mismatch and the user shouldn’t be allowed to upload the file.

Note: Even if the size is not less than 25kb and the resolution is not equal to 132*170px, it should give a format mismatch error based on the first format validation and it is incorrect.

From the above two examples we can conclude that:

In order to find the number of all possible conditions for the decision table, you can use the 2^n formula where n denotes the number of inputs; in example-1 there is the number of inputs is 2 (one is the Email id and the second is the Password).

Number of possible test conditions = 2^ Number of input conditions

Number of possible test conditions =2^2 = 4

Hence, in the case of example 1 we have covered four test cases.

Similarly in case of example 2, on a high level there are 3 different types of inputs such as the file format, the size and the file resolution. Applying the same 2^n formula:

Number of possible test conditions = 2^ Number of input conditions

Number of possible test conditions =2^3 = 8

Hence, in case of example 2 we have covered eight test cases.

Why Decision Table Testing is Important?

·   Decision table testing provides a systematic way of stating a complex business rule in the form of decision tables, which is useful for developers as well as for testers.

·   Decision tables testing technique can be used in test designs even if the test conditions are not used in specifications. This helps the testers to explore the effects of combinations of different inputs and other software states, that must correctly implement business rules.

·   While testing the behaviour of a large set of inputs where system behaviour differs with each set of inputs, the decision table testing provides good coverage and the representation is simple so it is easy to interpret and use.

·   The technique of equivalence partitioning and boundary value analysis are often applied to specific situations or inputs. However, if different combinations of inputs result in different actions being taken, this can be more difficult to show using equivalence partitioning and boundary value analysis. For combinations of inputs decision table testing design technique is preferable.

·   For example decision table for credit card interest rates. For same credit card,  interest rates varies based on different inputs such as new customer, loyalty point, coupons, etc. So in such cases creating a decision table based on the specification and different input combinations would be very useful.

Advantages of Decision Table Testing:

There are different advantages of using the decision table in software testing such as:

1. Decision tables testing technique aid the systematic selection of effective test cases.

2. Using this technique, complex business flows can be easily converted into the test scenarios and test cases.

3. Decision table testing can lead to have the beneficial side effect of finding problems and ambiguities in the specification.

4. This technique provides comprehensive coverage of all test cases that can significantly reduce the re-work on writing test cases and test scenarios.

5. With decision tables created once, the test case coverage becomes more accurate.

6. When the system behaviour varies depending on the inputs and is not consistent over a range of inputs, neither equivalent partitioning nor boundary value analysis can help, but a decision table can help us to design the test cases easily in such cases.

7. Decision tables are easy to understand, and everyone can use and implement this design and testing method, scenarios and test cases without prior experience.

Disadvantages of Decision Table Testing

1. As we saw above the formula of creating test cases out of a decision table is 2^n, hence when the number of input increases, the decision table becomes more complex. So, this is one of the major setbacks. 

2. This testing requires skilful and expert testers to handle complex decision tables, as there are many inputs in complex decision tables. For a beginner it may be difficult to deal with such complex decision tables and extract test case.

3. We have to maintain the decision table timely because of whenever there are any changes in the software, it is mandatory to incorporate the same in the decision tables. Therefore, you must maintain and update them frequently, which will result in more costs and efforts by the team.

4. Although the testing is efficient and beneficial, it can be a little time-consuming creating the table and extracting test cases post that. The more time, the more will be the testing costs.

Summary

Decision table testing is a powerful and effective black box testing technique that can help to ensure the accuracy and reliability of a software application. By using decision table testing, you can improve the quality of your software application and provide a better user experience.

Now that you have understood the decision table testing technique, you can begin using decision table to explore what the business rules are and what should be tested according to it, you may find the tables are very helpful for both testers, developers and other stack holders. A well-created decision table can help to sort out the right response of the system, depending on the input data, as it should include all conditions. It simplifies designing the logic and thus improves the development and testing of the product.

How decision tables are used in black box testing? Here’s how decision tables are used in black box testing:

• Identify the input conditions and possible values.
• Define the outcomes or expected results.
• Create corresponding decision tables in a tabular representation.
• Use this decision table to generate systematically design test cases.
• Start executing the test cases derived from the decision table.
• Report issues encountered, to the development team for resolution.

What is the formula for decision table testing? The formula for a decision table can be, 2^n formula where n denotes the number of inputs. Number of possible test conditions = 2^ Number of input conditions How many types of decision tables are there? On a high level there are two types of decision tables present in software testing.

• Extended entry table: In the extended entry decision table, the condition entries have more than two values. The decision tables use multiple conditions where a condition may have many possibilities instead of only ‘true’ and ‘false’ are known as extended entry decision tables.
• Limited entry table: In the limited entry decision tables, the condition entries are restricted to binary values i.e. True and False.

To build decision tables, the analyst needs to determine the maximum size of the table and eliminate any impossible situations, in consistencies or redundancies and simplify the table as much as possible.