Decision Tables: Structuring Test Cases for Multiple Conditions

 

By Andréia Ribeiro

When testing systems that involve multiple conditions and business rules, it can be challenging to ensure that all possible combinations are properly covered. In many cases, simply testing a few typical scenarios is not enough, and important combinations may be overlooked.

I have studied the structured approach to Decision Tables commonly taught in testing certifications such as ISTQB, which provides a formal methodology for organising conditions, rules, and expected outcomes. Additionally, during my software testing mentorship with Julio de Lima, I explored practical ways to apply Decision Tables in real-world scenarios.

What Are Decision Tables?

A Decision Table is a structured test design technique that helps testers organise complex logic and systematically derive test cases. It maps conditions (inputs or rules that affect system behaviour) and their corresponding actions or outcomes (expected results for each combination) in a structured format.

Essentially, it is a visual representation of “if this, then that” logic, where every scenario is explicitly listed. This makes it easier to identify which combinations of conditions should be tested and what the expected result should be.

Key Benefits:

• Ensures complete coverage of all rule combinations.
• Reduces the risk of missing important test cases.
• Provides a visual, easy-to-understand representation of complex business logic.

ISTQB Approach to Decision Table Testing

The ISTQB approach provides a formal methodology for creating Decision Tables and deriving test cases.

Steps According to ISTQB

1 Analyse Requirements

Identify business rules, input conditions, and expected outcomes.

2. Create Table Structure

List all conditions and possible actions. Each column represents a rule with a unique combination of conditions and its corresponding action.

3. Define Rules

Populate the table with all possible combinations of conditions (e.g., True/False or Yes/No) and their expected outcomes.

4. Simplify the Table

Remove redundant or impossible combinations, or merge rules that lead to the same action. ISTQB allows the use of a “don’t care” (–) symbol for conditions that do not affect the outcome.

5. Generate Test Cases

Each column in the final table represents a unique, executable test case, ensuring coverage of all relevant business rules.

Coverage is measured based on the total number of feasible rule columns. Infeasible combinations can be removed, and columns with conditions that do not affect the outcome can be merged to reduce the number of test cases.

Applying Decision Tables in E-Commerce

Testing multiple interacting conditions manually can be confusing and error-prone. Consider an example where an online store applies a discount only when certain conditions are met.

The system rules are:

• The user must be a VIP.
• The purchase amount must be greater than €100.
• The coupon must be valid.

If all conditions are true, the discount is applied; otherwise, it is not.

When multiple conditions interact like this, it’s easy to miss important combinations during testing. Decision Tables help by organising all conditions and expected outcomes logically.

Step 1 – Identify the Conditions (inputs/business rules)

In this example these are binary conditions (Yes/No). Non-binary conditions would increase the number of combinations.

Step 2 – Identify the Actions (system outcomes)

Define the possible system outcomes:

• Apply discount

• Do not apply discount

Step 3 – Create the full table with all possible condition combinations

With three binary conditions, the complete table contains:

2³ = 8 rules (columns)

Explanation:

R1: All conditions true → Discount applied

R2–R8: At least one condition false → Discount not applied

Step 4 – Simplify by merging equivalent rules or removing infeasible ones

Only one rule results in applying the discount (all conditions true).
The remaining rules produce the same outcome (no discount) and can be merged using “don’t care” (–) values to simplify the table.

The simplified table reduces eight possible combinations to two effective rules while maintaining full coverage of the business logic.

A dash (–) indicates the condition does not matter for that rule.

Practical Example from Mentorship with Julio de Lima

In addition to the formal approach defined by ISTQB, more practical methods are often used in real-world projects. One such approach, presented by Julio de Lima, connects business rules directly to user inputs in a systematic way to facilitate test case generation.

Using this method, the tester identifies input conditions, their possible variations (or partitions), and the corresponding system actions, then organises this information into a decision table. The resulting table can be used to derive test cases that accurately reflect the system’s business rules.

Example: Money Transfer Rules

Rule 1: Transfers must be at least €10. Amounts lower than this are not allowed.

Input: Transfer amount

In this case, boundary value testing is particularly relevant, as the minimum allowed value is critical to the system behaviour.

Rule 2: Transfers of €5,000 or more require token authentication.

Inputs:

• Transfer amount (less than €5,000 / greater than or equal to €5,000)

• Token status (valid / invalid / not provided)

For transfers below €5,000, token authentication is optional. However, if a token is provided, it must be valid; otherwise, the transfer is rejected.

Considering these inputs, the possible combinations of conditions are:

2 × 3 = 6 combinations

Example test cases derived from this scenario:

This practical approach demonstrates how Decision Tables can incorporate related input variables and ensure that all meaningful combinations are considered, particularly when multiple inputs influence the system outcome.

Lessons Learned

Decision Tables are particularly useful when multiple rules interact.
They help communicate test scenarios clearly to developers, stakeholders, and other testers.
Applying the practical method from my mentorship helped me think more systematically and uncover cases I might have overlooked.
Using structured Decision Tables improves test coverage and enhances software reliability.

Deriving Test Cases

Once the table is created, test cases can be derived directly from it.
This ensures that tests accurately reflect the rules and cover all meaningful combinations of conditions.

Why Decision Tables Are Useful

• Organise complex logic clearly

• Reduce the risk of missing important combinations

• Derive consistent, traceable test cases

• Validate business rules effectively

Key Takeaways

• Decision Tables help structure testing when multiple conditions affect outcomes

• They make it easier to visualise and validate business rules

• They help derive complete and logical test cases from defined system behaviour

• While Decision Tables can become complex in real systems, combining formal ISTQB methods with practical approaches from mentorship provides both structure and real-world insight

Have you applied Decision Tables in your testing?
Which types of systems or features do you think benefit most from this technique?
Share your thoughts or examples in the comments. I’d love to hear how you use this method in practice!

References

• Mentorship: Software Testing Mentorship with Julio de Lima

• Graham, D., van Veenendaal, E., Evans, I., & Black, R. (2008). Foundations of Software Testing.

• ISTQB Glossary & Syllabus. International Software Testing Qualifications Board.