Test Case Writing Made Simple With Decision Tables


Hey Testing Geeks! Before jumping into the article, I would like to start with a little incident I once had.

Some time ago, my team reviewed test scenarios for a medical prescription upload feature where the user could upload PDF, JPG, or JPEG files, up to 2 Mb in size.

While reviewing the scenarios, my team lead identified a missing scenario and asked what should be the expected behavior when someone uploads more than 2 Mb .xlsx files or any other extension apart from PDF, JPG, or JPEG.

I answered based on my understanding that the system should show an error message, even though I had not covered that scenario in my list. My team lead gave me some great advice back then; if I had used the decision table technique, I wouldn’t have missed that scenario.

Decision tables are a black box testing technique used to define test scenarios, also known as the cause-effect technique. Software testing uses decision tables as a systematic approach to representing the expected system behavior according to variations of system inputs.

Nowadays, I use decision tables regularly for writing my test scenarios. So today, we will go through decision table testing in detail, I’ll show you an example, and hopefully, I can help you improve your testing skills as my team lead helped me. Let’s get started!

Decision Table Testing

Decision table testing is a software testing technique used to lay out the Software’s behavior by providing various user inputs and the expected outcome.

The decision table consists of all the conditions taken from the requirements, applying the different input combinations, and defining the expected action for each scenario.

Conditions / InputRule 1Rule 2Rule 3Rule 4
Condition 1
Condition 2
Actions / OutputRule 1Rule 2Rule 3Rule 4
Action 1
Action 2
Action 3
Decision Table Template

Let’s look at a real example to understand the decision table process in detail.

Step-by-step Example of Decision Table Testing

Let’s consider an example. We’ll consider an online store that provides discounts to its users based on the following business rules:

  • The user is eligible for a 10% discount if they have a store membership.
  • The user is eligible for a 25% discount if they are part of the staff.
  • The user is eligible for a 15% discount on their birthday.
  • Users can accumulate a maximum of two deals at a time.

Now let’s see how we get all this into a Decision table. First, we need to define our conditions:

Conditions / InputRule 1Rule 2Rule 3Rule 4
Has store membership
Is staff
Is their birthday
Decision Table: Conditions

Second, we need to lay out all the possible input variations. The number of variations is simple math is 2n, where n is the number of inputs. We have three inputs and 23 = 8 input variations in our example.

Conditions / InputRule 1Rule 2Rule 3Rule 4Rule 5Rule 6Rule 7Rule 8
Has store membershipTFTFTFTF
Is staffTTFFTTFF
Is their birthdayTTTTFFFF
Decision Table: Input combinations

We can write down all the combinations we defined on the decision table, these will be the basis for our test cases:

  1. The User is eligible for staff, store membership, and birthday discounts.
  2. The User is eligible for staff and birthday discounts.
  3. The User is eligible for store membership and birthday discounts.
  4. The user is eligible for a birthday discount.
  5. The User is eligible for staff and store membership discounts.
  6. The User is eligible for a staff discount.
  7. The User is eligible for a store membership discount.
  8. The user is not eligible for any discount.

Now let’s complete the decision table with the actions, the rules to apply, and calculate the total discount for each case.

Conditions / InputRule 1Rule 2Rule 3Rule 4Rule 5Rule 6Rule 7Rule 8
Has store membershipTFTFTFTF
Is staffTTFFTTFF
Is their birthdayTTTTFFFF
Actions / OutputRule 1Rule 2Rule 3Rule 4Rule 5Rule 6Rule 7Rule 8
10% DiscountFFTFTFTF
25% DiscountTTFFTTFF
15% DiscountTTTTFFFF
Total Discount40%40%25%15%35%25%10%0%
Online store discounts decision table

With our Decision table complete, writing down our test scenarios is now a piece of cake:

  1. The user is eligible for staff, store membership, and birthday discounts.
    Expected result: The user is eligible for all discounts, but a maximum of 2 can be applied. For the best deal, a 40% discount is applied.
  2. The user is eligible for staff and birthday discounts.
    Expected result: A 40% discount is applied.
  3. The user is eligible for store membership and birthday discounts.
    Expected result: A 25% discount is applied.
  4. The user is eligible for a birthday discount.
    Expected result: A 15% discount is applied.
  5. The user is eligible for staff and store membership discounts.
    Expected result: A 35% discount is applied.
  6. The user is eligible for a staff discount.
    Expected result: A 25% discount is applied.
  7. The user is eligible for a store membership discount.
    Expected result: A 10% discount is applied.
  8. The user is not eligible for any discount.
    Expected result: A 0% discount is applied.

Why Decision Table Testing is Important

As we saw with the example above, decision table testing is vital for breaking down all the combinations and expected behavior in software development.

Decision table testing provides a way to guarantee a good test case coverage since the technique makes you cover all the combinations for the inputs that are defined in the requirements.

When you don’t use decision tables to map out all the conditions and combinations of your business requirements, you may not cover critical use cases and miss significant defects that could impact the business and user experience.

Decision table testing is also an excellent method for identifying gaps in requirements. Once you map out all the condition variations and actions, it will be easy to determine if the expected result for a given rule is unclear or not specified in the requirements.

Advantages of Decision Table Testing

  • Ensuring a good test coverage since every combination and expected behavior is covered.
  • Catching any gaps in the requirement early on because every condition is mapped as a rule in the Decision Table.
  • Decision tables are not limited to the QA team and can be used by anyone to map requirements easily.
  • Decision tables convert complex requirements into a clear tabular format.

Disadvantages of Decision Table Testing

  • Decision Table Testing is challenging when the requirements are not clear.
  • The decision Table will become large and complex if there are many conditions or inputs.

Conclusion

We can conclude that using Decision Tables proves to be a fundamental technique in Software testing. It is a technique that not only the testers can use but can also be utilized by anyone to break down any complex requirement with just a straightforward table of input combinations vs. expected results.

We should consider the usage of Decision Tables wherever there are various conditions and combinations for our test cases.

Kudos to my Team Lead for introducing me to this topic; it’s such a valuable topic to know and share with the community.

Happy Testing!! 😃

Johnny

Hi there, I'm Johnny! Since the beginning of my career, I have tested a wide variety of software applications. I created Tester Tips to share my experience, help you master testing, and watch your career progress.

Recent Posts