Decision Table Testing

Decision Table Testing: Complete Guide for ISTQB CTFL Exam

What is Decision Table Testing?

Decision table testing is a black-box test design technique used to identify test cases where the outcome of a test depends on the combination of inputs or conditions. It is a systematic approach to testing multiple combinations of conditions and their corresponding actions in a structured, tabular format.

A decision table, also known as a cause-effect table, is used to document and organize the relationships between different conditions (inputs) and the actions (outputs) that result from those combinations.

Why is Decision Table Testing Important?

1. Handles Complex Logic: Decision table testing is particularly effective when dealing with business rules that involve multiple conditions and their combinations. It ensures that all possible combinations are considered and tested.

2. Comprehensive Coverage: It helps achieve high test coverage by systematically exploring all combinations of conditions, reducing the risk of missing critical test scenarios.

3. Identifies Missing Cases: The structured format makes it easy to spot gaps in requirements or logic that may have been overlooked during development.

4. Cost-Effective: By organizing test cases in a table format, it reduces redundancy and allows testers to identify the minimum number of test cases needed to cover all conditions.

5. Improves Communication: Decision tables provide a clear, visual representation of business rules that can be easily understood by both technical and non-technical stakeholders.

6. Detects Logic Errors: It helps identify inconsistencies, contradictions, and errors in the business logic before testing begins.

How Decision Table Testing Works

Step 1: Identify Conditions (Causes)

List all the input conditions or causes that affect the system behavior. Each condition is typically a Boolean (True/False) or has a limited set of values.

Example: For a bank account withdrawal system:

• Account Active (Yes/No)
• Sufficient Balance (Yes/No)
• Daily Limit Not Exceeded (Yes/No)

Step 2: Identify Actions (Effects)

List all the possible outputs or actions that result from different combinations of conditions.

Example: For the bank withdrawal system:

• Allow Withdrawal
• Reject - Account Inactive
• Reject - Insufficient Balance
• Reject - Daily Limit Exceeded

Step 3: Create the Decision Table

Create a table with rows for conditions and columns for different combinations. Each column represents a unique test case scenario.

Example Table:

Step 4: Simplify Using Reduced Decision Tables

Often, some conditions don't affect the outcome in certain scenarios. These can be marked as 'Don't Care' (–) to reduce the number of test cases while maintaining coverage.

Step 5: Generate Test Cases

Each column in the decision table represents one test case with a specific combination of condition values and expected actions.

Key Concepts in Decision Table Testing

Combinations: With n conditions, there can be 2^n possible combinations (for Boolean conditions). For example, 3 conditions = 8 combinations.

Reduced Decision Tables: Some conditions may not affect outcomes in specific scenarios, allowing 'Don't Care' entries to reduce test cases.

Mutually Exclusive Actions: In a well-designed decision table, only one action occurs for each test case combination (or clearly defined multiple actions).

Complete Decision Tables: All possible combinations of conditions are considered, ensuring thorough coverage.

Types of Decision Table Testing

1. Limited Entry Decision Table: Each condition has only two values (True/False or Yes/No). This is the most common format.

2. Extended Entry Decision Table: Conditions can have multiple values beyond just True/False, allowing more complex scenarios to be represented.

3. Mixed Entry Decision Table: A combination of limited and extended entry tables.

Advantages of Decision Table Testing

• Systematic and organized approach to test case creation
• Ensures comprehensive coverage of condition combinations
• Easy to identify missing or contradictory business rules
• Reduces number of test cases through intelligent reduction
• Clear documentation of expected outcomes
• Effective for testing complex business logic
• Improves communication among team members

Limitations of Decision Table Testing

• Not suitable for GUI testing or sequential operations
• Can become unwieldy with many conditions (2^n combinations)
• Requires clear understanding of business rules upfront
• May not catch boundary value issues on their own
• Less effective for testing continuous or dependent conditions

Exam Tips: Answering Questions on Decision Table Testing

Tip 1: Understand the Difference Between Conditions and Actions
Always clearly identify what are conditions (inputs/causes) and what are actions (outputs/effects). Conditions determine the action; actions are the results. In exam questions, read carefully to distinguish between them.

Tip 2: Count Combinations Correctly
Remember the formula: with n Boolean conditions, you have 2^n possible combinations. For 3 conditions, that's 2^3 = 8 combinations. Know this formula as exam questions often ask about the number of possible test cases.

Tip 3: Recognize When to Reduce Test Cases
Look for scenarios where a condition is 'Don't Care' (marked as –). This occurs when the outcome is the same regardless of that condition's value. The ability to identify these situations shows understanding of optimization.

Tip 4: Identify Contradictions or Impossible Combinations
Exam questions may ask you to identify illogical or impossible combinations in a decision table. These are marked with a dash or left empty. Be alert to these.

Tip 5: Match Test Cases to Conditions and Actions
When given a decision table, ensure you can correctly map each test case combination to its expected action. Practice matching rows and columns accurately.

Tip 6: Understand Extended vs. Limited Entry Tables
Know the difference: limited entry has binary (Y/N) conditions while extended entry can have multiple values. Questions may ask which type is more appropriate for a scenario with multiple discrete values.

Tip 7: Relate Decision Tables to Equivalence Partitioning
Understand that decision table testing often works alongside equivalence partitioning. While partitioning groups similar inputs, decision tables explore how different combinations interact.

Tip 8: Practice Creating Tables from Requirements
Exam questions often provide business rules and ask you to create a decision table. Practice extracting conditions and actions from written requirements. Look for keywords like "if," "and," "or," and "then."

Tip 9: Know the Terminology
Be familiar with key terms: limited entry, extended entry, causes, effects, conditions, actions, decision table, reduced table, don't care. The exam may test vocabulary.

Tip 10: Calculate Minimum Test Cases for Reduced Tables
When asked to reduce a decision table, count the number of 'Don't Care' entries and calculate the actual minimum number of test cases needed. This requires understanding which conditions truly affect outcomes.

Tip 11: Identify Mutually Exclusive and Comprehensive Conditions
A good decision table should have mutually exclusive conditions (no two can be true simultaneously) and be comprehensive (cover all possible scenarios). Be ready to critique incomplete tables.

Tip 12: Apply Decision Tables to Business Scenarios
Exam questions often present real-world scenarios (loan approval, discount calculations, access control). Quickly identify conditions and actions, then structure them into a table format.

Sample Exam Question and Solution

Question: A travel booking system applies discounts based on the following rules:
- If the customer is a frequent flyer AND books more than 3 months in advance, they get a 20% discount
- If the customer is a frequent flyer AND books within 3 months, they get a 10% discount
- If the customer is NOT a frequent flyer AND books more than 3 months in advance, they get a 5% discount
- If the customer is NOT a frequent flyer AND books within 3 months, they get no discount

Create a limited entry decision table for this scenario and identify the number of test cases needed.

Solution:

Answer: 4 test cases are needed. With 2 Boolean conditions, we have 2^2 = 4 combinations, and all are valid and distinguishable, so no reduction is possible.

Common Pitfalls to Avoid

• Confusing conditions with actions: Always clearly separate inputs from outputs
• Not identifying all conditions: Read requirements thoroughly to find all factors affecting outcomes
• Over-testing: Don't create redundant test cases; use reduction techniques appropriately
• Ignoring impossible combinations: Some combinations may be logically impossible; mark these explicitly
• Incomplete action definitions: Ensure each combination maps to at least one action
• Missing 'Don't Care' opportunities: Always look for conditions that don't affect outcomes in certain scenarios