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

Decision Table Testing advocates an uncomplicated and assured strategy for pinpointing test scenarios for complex Business Logic.

Various avenues exist to be explored when it boils down to test case design techniques. This composition will demystify the practical application of the Decision Table method in manufacturing test cases intended for applications that embody complex Business Logic.

Exemplifying with an instance:

It is a general understanding that business regulations and validations form a pivotal component of client requirements. These rules and reasoning are often depicted using a logical course of action flowchart by Business Analysts or clients.

Containing multiple branches, nodes, and decision boxes, a complex need’s logical process scaffold is noticeable. It becomes mandatory as testers to traverse all these branches and probe every dimension of the intricate logical tree comprehensively. I have worked with different styles of test case and test scenario building techniques when confronted with such formidable business flows to facilitate the process.

Consequently, I noted that utilizing the Decision Table Testing method phenomenally aids in streamlining the test scenario crafting for robust Business Logic. Here’s how the Decision Table technique can make the process seamless:

Example: Forming Test Cases for a Login Display with Decision Table Method:

Let’s turn our attention to a Decision Table example anchored on the succeeding business stipulation for a login display.

Fig: 1.0 Prototype Business flow chart

The initial stride is assigning designations or counts to all the branches and leaves, as demonstrated next.

1, 2, 3 symbolize leaves, while a, b, and c represent branches.

Subsequently, let’s form a Decision table as exemplified below: (Click to magnify the image)

Fig 1.1 Decision grid for business flow fig 1.0

Vital Considerations

• All validations portrayed in the decision boxes must match the columns in the grid.
• The Decision table should cover all outcomes (leaves) stated in the flowchart.
• The combinations column should contain all combinations of inputs required to attain a particular result and these combinations can be utilized when scripting test cases.
• Upon completion of the Decision grid, it becomes essential to authenticate that every branch and leaf within the logical tree is encompassed.

Advantages Of Using Decision Table Technique

#1) This method can conveniently accommodate any complex Business trajectory depicted as a chart.
#2) It imparts swift confidence in the fashioned test cases, mitigating the requirement for multiple reassessments.
#3) It is user-friendly and empowers anyone to formulate test scenarios utilizing this Decision table template.
#4) It trims the requirement for iteration, as it ensures comprehensive coverage from the outset.

Limitations Of Using Decision Table Technique

#1) Certain test case formulation techniques such as Boundary Value Analysis and Equivalence partitioning may not be instantly integrated into this template. Nevertheless, these techniques can be recorded in the combinations column and utilized when scripting test cases.

Prior to discussing the reasons why other test case scripting techniques may not assure accuracy to the extent Decision tables do, noteworthy other Black box and White box test case scripting methods should be mentioned.

Other Test Case Design Techniques

#1) Boundary Value Analysis: This method emphasizes on electing test cases that comprise values at the confines of a prescribed range.
#2) Equivalence Partitioning: Famously known as Equivalence Class Partitioning, this procedure categorizes conditions into partitions and picks a single input from each partition for testing.
#3) State Transition Testing: This black-box method is employed to design test cases for systems that navigate between finite states in response to distinct events.
#4) Error Guessing: This methodology counts on tester competence to identify sections of a program that bear the highest probability of errors. It is essentially a skill-oriented technique devoid of specific rules.
#5) Use Case Testing: In this procedure, test cases are drawn out from user case/scenarios, which outline interaction between clients and systems.
Supplementary Test Design Techniques:
#6) Statement coverage
#7) Condition Coverage
#8) Exploratory testing

Why aren’t test case design methods for Business logic as significant as Decision Tables?

#1) Boundary Value Analysis and Equivalence class partitioning are principally apt for numerical ranges and lengths. Solely these techniques cannot guarantee 100% Test Coverage for business law.

#2) Error Guessing is heavily dependent on experience, but experience by itself isn’t substantial.

#3) While the State Transition method can assure coverage of the entire logical tree, unlike the Decision Table method, it does not provide a mode of documentation or artifact (fig 1.1).

Conclusion

To ensure optimum Test Coverage when scripting test cases for business logic, the following steps are recommended:

Step #1) Leverage the Decision Table test case design technique to attain 100% logical coverage.
Step #2) Integrate Boundary Value Analysis and Equivalence partitioning to cover various input ranges.
Step #3) Keep in mind combinations and permutations for field-level validations, although all permutations are not necessary.
Step #4) Engage Error guessing (besides the errors spotted through the prior three steps) relying on the experience.

Combining these methods effectively can unearth nearly all potential test scenarios for any program being tested.

About the author: Hari Narayan is a software examination professional encompassing over three years of expertise in designing test cases for complex Business Logic. He presently serves at Plintron Global Technologies.

Do share which test case design method you commonly exercise on your projects and which methodology you deem the premier based on your exposure.

We warmly invite your constructive feedback and suggestions on this post.