# How to Write Complex Business Logic Test Scenarios Using Decision Table Technique

There are several test case design techniques. In this article, we will learn how to use Decision Table technique effectively to write test cases for an application with complex business logic.

Decision table testing is an easy and confident approach to identify the test scenarios for complex business logic.

Here is an illustration of example:

We all know that the rules and validations of a business take up a major portion of the requirements given by the customers. While observing how these requirements are represented and communicated to the entire project team by Business Analyst’s or customers, we come to know that most of such business rules and logic and are presented in a logical process flow diagram.

A logical process flow diagram for a complex requirement comprises of many branches, nodes, and decision boxes. Hopefully, we testers are expected to cover all those branches and touch every nook and corner of such a complex logical tree. I have also faced such complex business flows and tried many test case/test scenario preparation techniques for making the process easier.

Finally, I found the decision table testing technique to be highly useful in this aspect. Here is how a decision table technique can make the test scenario preparation for complex business logic easier.

E.g. Writing test cases for a login screen using the Decision Table technique:

Let’s take a Decision Table example of below business requirement for a login screen.

Fig: 1.0 Sample business flow diagram

The first step we do is to name all the branches and leave with numbers or alphabets as below.

1, 2, 3 are the leaves and a, b & c are the branches.

Then, we have to create a decision table as shown below: (Click to enlarge image)

Fig 1.1 Decision table for business flow fig 1.0

### Points to Remember

• All the validations specified in the decision boxes should be made of the columns on the table.
• All the results (leaves) mentioned in the flow diagram should be covered in the decision table.
• All combinations of inputs needed to obtain a certain result shall be mentioned in the combinations column and can be included while writing the test cases.
• After completing the decision table, one has to just verify whether all the branches and leaves in the logical tree are covered.

### Advantages of Using Decision Table Technique

#1) Any complex business flow represented as a diagram can be easily covered in this technique.
#2) It provides quick confidence on the test cases. One need not have to review his own test cases multiple times to gain confidence.
#3) Easy to understand. Anyone can make test cases from this decision table template.
#4) Rework on the test cases and test scenario can be totally avoided, as it gives complete coverage at the first shot.

### Limitations of Using Decision Table Technique

#1) Certain test case preparation techniques like Boundary value analysis, equivalence partitioning cannot be directly accommodated in this template. But, one can note it down in the combinations column and use them while writing test cases.

Before explaining why other test case writing techniques cannot assure as much accuracy as Decision tables, I would like to quickly remind other black box and white box test case writing techniques.

### Other Test Case Design Techniques

1) Boundary value analysis is a software testing technique in which test cases are designed to include representatives of boundary values in and out of a given range.

2) Equivalence partitioning also, called Equivalence Class Partitioning is a software testing technique that divides the given condition into partitions and one input data from each partition can be chosen for testing.

3) State transition testing is a black box testing technique, which can be used to design test cases for a system that acquires a finite number of states and can transit from one state to another upon specific events.

4) Error Guessing is a technique where the experience of a tester is used to find the errors or part of an application with the highest possibility of finding errors. This is skill-based technique without any rules.

5) Use case testing In this technique, use cases/scenarios are used to write the test cases. Interaction of users and system is described in a use case.

Some more test design techniques:
6) Statement coverage
7) Condition Coverage
8) Exploratory testing

Why can’t other test case design techniques for business logic prove to be useful as Decision Tables?

1) Boundary value analysis and Equivalence class partitioning are meant for numeric ranges and length. Both of these techniques alone cannot ensure 100% test coverage for business rules.

2) Error guessing is more about the experience. Though experience is required, it cannot prove to be everything.

3) With state transition testing technique, one can ensure that all parts of the logical tree are covered but it does not suggest document or artifact as decision table technique ensures coverage with a decision table (fig 1.1).

### Conclusion

For writing test cases for business logic, it is advisable to follow the below steps to prepare test cases so as to ensure maximum test coverage:

Step #1) Use decision table test case design technique to attain 100% logical coverage.
Step #2) Boundary value analysis and Equivalence partitioning for covering various ranges of inputs.
Step #3) Combinations and permutations for field level validations (though not all permutations are required).
Step #4) Error guessing (apart from the errors that can be identified from the above three steps) with experience as a final touch

With the right combination of all these techniques, I hope you will be able to discover almost all test scenarios for any application under test.

About the author: Hari Narayan is a software testing professional with more than 3 years of work experience on writing test scenarios for complex business logic. He is currently working with Plintron Global Technologies.

Let us know which test cases design technique you use most often on your project? And which is the best method according to your experience?

Feel free to share your valuable comments/suggestions about this article.

### 13 comments ↓

#1 Kiran J

very simple to understand. We are mainly using only two methods EP and BVA to write test cases, and error guessing to some extent. thanks for sharing.

#2 Kiran Kadam

Great article on decision table tech.
Thanks a lot Vijay & Wish you very very happy diwali.
Keep up the good work!

#3 Natalya

Thank you for the article! It contains very useful info.
On my projects I use most often Decision tables, EP & BVA and State transition testing. Of course, Error Guessing is used as well.

#4 Karuvarasan

Thank you Vijay and Swati. Happy diwali to you and your family.

Thanks Hari Narayan for sharing this wonderful topic

#5 Shrikanth

Very Good Article. Kudos to the team for posting this ..

#6 murali

Great work. Thanks for the same. If possible try to post about managing all type of testcases that you have mentioned in the conclusion part (step1,step 3 etc ) with an example and template. For example how we can create all types of testcases for a simple project(scenario based, validation based, equivalence portioning, UI testing etc) and manage it using excel.

#7 JAI

Can u tell me what is the difference between State transition testing and Decision table testing and when to use to what? I understand both but I dont get the difference and when to use what. Please help

#8 Haritha

Is usecase testing, a part of decision testing?

Can you give an example for each in detail taking use case and business logic in particular?

Thanks for your time and great topics!

#9 Inder

Can u give State transition technique? In what ways can we test a text field using this method?

Great post…Thanks!!

#10 Nirav

Thanks for article..!

It’s very useful for design new test cases of business logic.
If possible than can you pls explain with one very complex example…with this method

#11 Hong Tran

A great article. Thanks!!!

#12 surendar

FOLLOWING ARE THE REQUIREMENTS WE HAD WHAT ARE THE SCENARIOS THAT WE HAVE FROM THE FOLLOWING
1.to field is mandatory and will accept 1 or more more email ids
2.cc field will accept 1 or more more email ids
3.subject is mandatory field and accept 256 characters and .html and .doCS format
4.test field will accept any format of text
5. attachments will accept max10mb file with .pdf and .jpg files

#13 Smita

Why can not first alert:” Please enter non blank credentials” be branch? There are total 4 branches. Please explain if I am wrong.