Understanding the Role of Decision Table Testing

One type of software testing is Decision Table Testing. In real-world projects, it’s often created using Excel. Its visual clarity makes it easy to understand even for non-technical team members who have strong domain knowledge.

On the other hand, when confirming the behavior of the implemented code, structural testing (like unit tests) is commonly used.

(If you'd like to dive deeper into structural testing, feel free to check my previous post: Understanding Software Test Coverage Criteria Step by Step: From Line Coverage to MC/DC)

At first glance, these two approaches may seem completely different. However, understanding why both are necessary for testing the same logic is extremely important in practice. This article explores the reasons and background behind that.

Basic Structure of a Decision Table

A decision table has a very simple structure. Conditions are written vertically, with the outcome listed at the bottom. Each horizontal column represents a variant—a combination of input values for each condition.

• Conditions: Assumptions or inputs used to make decisions (rows)
• Variants: Test cases created from combinations of conditions (columns)

Using this kind of table helps organize test cases in a structured and comprehensive way.

Just like structural testing, there are also various strategies depending on the testing purpose.

Test Strategy Comparison in Decision Tables

Why Do We Use Different Approaches?

At this point, you might wonder:

“If we confirm specifications using a decision table → implement the code based on those specs → verify behavior using structural testing...

then do we really need decision table-based testing?”

That’s a fair question.

However, even if we’re testing the same logic, the focus of each approach is different — and that’s why we need both.

Why Is Decision Table Testing Necessary?

Even if specifications are well-organized using a decision table and proper structural tests are conducted, decision table-based testing still brings unique value in the following ways:

1. Implementation Doesn’t Always Match the Specification

• There can be overlooked or misunderstood requirements during implementation.
• Decision table testing verifies the intended decision logic by testing strictly against the specification.

2. Structural Testing Can’t Detect Missing Logic

• Structural testing checks only what’s written in the code.
• It cannot detect what’s missing.
• A decision table helps reveal decisions that should exist but don’t.

3. Clarifies Test Coverage

• With a decision table, it’s clear which conditions and results are being tested.
• It makes it easier to find gaps or redundancies in the test cases and enables better reviews among team members.

Relationship Between Decision Tables and Structural Testing

Creating test cases based on a decision table can indirectly cover code branches (like if statements).

However, structural testing alone is not enough in cases like:

• Logic using polymorphism (inheritance or dynamic dispatch)
• Conditions depending on configuration files or database values

Since these aren’t explicitly shown as branches in the code, they may be missed by structural tests.

The following section provides concrete examples.

When Logic Uses Polymorphism

Polymorphism means that the same method name can behave differently depending on the class. This is a key feature of object-oriented programming.

// Java
class User {
    void showDiscount() {
        System.out.println("No discount");
    }
}

class PremiumUser extends User {
    void showDiscount() {
        System.out.println("20% discount");
    }
}

User u = getUser();  // We don't know if it's a regular or premium user
u.showDiscount();    // Behavior changes depending on the class at runtime

In this case, the branching is not done with if statements but by the type of class.
So, structural testing (which follows code branches like if) may miss this logic.

When Conditions Depend on Config Files or Databases

Sometimes, the behavior of an app is controlled by values in external files, not by conditions written in the code.

// config.json
{
  "isFeatureEnabled": true
}

# Python
if config["isFeatureEnabled"]:
    enable_feature()

In such cases, model-based testing (like decision tables) lets you verify the logic from a specification point of view.
In other words:

Structural testing checks whether the code behaves as written.

Model-based testing checks whether the right behavior or decision is included in the first place, from a user or specification perspective.

It’s especially useful to detect missing logic or misunderstood design that can’t be seen from code alone.

Structural Testing

Focus: Which branches are executed?

• Focuses on code structure (if statements, loops)
• Does not consider the software’s purpose or meaning
• Can be done with the specification and source code

Model-Based Testing

Focus: Are the necessary decisions being made?

• Requires domain knowledge and user perspective
• Uses models (like decision tables) to represent “what decisions should be made and how”
• Accessible to non-engineers and upstream stakeholders

Summary

Decision table-based testing offers several practical strengths and benefits:

• Handles non-Boolean values easily (e.g., capacity = none / 0GB / 8GB / unlimited)
• Easy to understand for domain experts, helpful for reviews and prioritization
• Can detect missing specifications that haven't been implemented

Decision tables act as a bridge from upstream to downstream phases.

They clarify specifications, guide design and implementation, and verify that the software behaves as specified.

By combining them with structural testing, we can both “build it right” and “build the right thing.”

This dual approach ensures high-quality software by covering both missing logic and implementation mistakes.