Decision Table Testing

Decision Table Testing is a test design technique used to test complex business rules that depend on multiple conditions.

It represents different conditions, combinations, and expected actions in a structured table. This helps testers identify combinations that might otherwise be missed.

It is especially useful for rule-heavy systems, such as discounts, loan approvals, insurance, user permissions, eligibility rules, and payment processing.

Why Use Decision Tables?

When a feature depends on several conditions, it can be difficult to identify all possible combinations.

For example, an e-commerce application may provide a discount when:

• The customer is a premium member.

• The order amount is at least $100.

Testing only the individual conditions may not be enough. The tester should verify how the system behaves when the conditions are combined.

Decision Table Testing provides a systematic way to identify these combinations.

Basic Structure

A decision table generally contains:

• Conditions — factors that affect the decision.

• Condition Values — possible values for each condition, such as Yes/No.

• Actions — what the system should do.

• Rules — combinations of conditions and their expected actions.

Example: Free Shipping

Suppose an e-commerce system provides free shipping when:

• Order amount is at least $100, and

• Customer is a premium member.

The possible combinations are:

Rule 1

• Order ≥ $100 → Yes

• Premium member → Yes

• Expected action → Free shipping

Rule 2

• Order ≥ $100 → Yes

• Premium member → No

• Expected action → Shipping charge

Rule 3

• Order ≥ $100 → No

• Premium member → Yes

• Expected action → Shipping charge

Rule 4

• Order ≥ $100 → No

• Premium member → No

• Expected action → Shipping charge

Each rule can become one or more test cases.

Step-by-Step Process

1. Identify the Conditions

Start by identifying the factors that affect the system's behavior.

Example:

• Is the customer a premium member?

• Is the order amount at least $100?

2. Identify Possible Values

Determine the possible values for each condition.

For example:

• Premium member → Yes / No

• Order ≥ $100 → Yes / No

3. Identify the Actions

Determine what the system should do for each combination.

Examples:

• Apply free shipping.

• Charge shipping fee.

• Apply discount.

• Reject transaction.

4. Create the Rules

Combine the condition values to identify different possible situations.

Each meaningful combination represents a rule that should be considered for testing.

5. Convert Rules into Test Cases

Each important rule can be converted into one or more test cases with appropriate test data and expected results.

Real-World Example: Login Access

Suppose a system allows access only when:

• Username and password are correct.

• The account is active.

Conditions:

• Credentials correct → Yes / No

• Account active → Yes / No

Possible rules:

Rule 1

• Correct credentials → Yes

• Account active → Yes

• Result → Login successful

Rule 2

• Correct credentials → Yes

• Account active → No

• Result → Login rejected

Rule 3

• Correct credentials → No

• Account active → Yes

• Result → Login rejected

Rule 4

• Correct credentials → No

• Account active → No

• Result → Login rejected

This ensures that the tester does not verify only the successful login scenario.

When to Use Decision Table Testing

Decision tables are particularly useful when:

• Multiple conditions affect the result.

• Business rules are complex.

• Different combinations produce different outcomes.

• There are many Yes/No or True/False conditions.

• Requirements contain business rules or policies.

• Missing a combination could cause significant business impact.

Common examples include:

• Discount and promotion rules

• Loan approval

• Insurance eligibility

• Payment processing

• User permissions

• Subscription plans

• Shipping rules

• Tax calculations

• Account access

• Approval workflows

Advantages

• Helps identify important combinations systematically.

• Reduces the chance of missing business-rule scenarios.

• Makes complex requirements easier to understand.

• Helps convert business rules into test cases.

• Provides clear traceability between conditions and expected actions.

• Can reveal conflicting or missing business rules.