Session 3.3 - Decision Table Techniques

Module 3: Dynamic & Static Testing | Duration: 1 hour

Learning Objectives
  • Translate complex business rules into decision tables and validate coverage.
  • Derive test cases from condition-action combinations systematically.
  • Reduce ambiguity by representing rule conflicts and gaps explicitly.

Concept Overview

Decision table testing is a rule-based design technique used when output depends on multiple conditions. It converts policy logic into a structured table so every meaningful combination is visible and testable.

Best use cases
Discounts, eligibility, approvals, penalties, compliance rules, and workflow authorizations.
Core benefit
Prevents missing combinations that are easy to overlook in prose requirements.
Testing outcome
Each column (rule) in the table maps directly to one or more test cases.

Why Decision Tables?

If there are n binary conditions, naive combinations are 2^n. Decision tables help you keep this manageable, identify invalid combinations, and document exact expected actions.

When to prefer this over simple equivalence tests
  • Output depends on interaction of multiple conditions, not one field at a time.
  • Rules include precedence (e.g., "if blocked, deny regardless of balance").
  • Compliance/contract logic must be auditable and unambiguous.

How to Build a Decision Table

Step-by-step method
  1. Extract all atomic conditions from requirements.
  2. List all possible condition combinations (rules).
  3. Mark impossible combinations with "-" or remove with justification.
  4. Map expected actions for each valid rule.
  5. Generate at least one test case per remaining rule.
  6. Review for conflicts (same conditions, different actions) and gaps (no action defined).
Notation tip
Use Y, N, and - (don't care) to keep tables readable.
Traceability tip
Name columns R1, R2, ... and map tests as TC-R1, TC-R2.
Quality tip
Peer review the table before test execution to catch requirement ambiguity early.

Worked Example: Loan Approval Rules

Policy: Loan is approved if applicant is salaried, credit score is at least 700, and no prior default. If prior default exists, always reject.

Conditions / Actions R1 R2 R3 R4 R5 R6
C1: Salaried?YYYNNN
C2: Score >= 700?YYNYNY
C3: Prior default?NYNNNY
A1: Approve loanYNNNNN
A2: Reject loanNYYYYY
Derived test cases (sample)
  • TC-R1: Salaried=Y, Score=750, Default=N -> Approve.
  • TC-R2: Salaried=Y, Score=750, Default=Y -> Reject (override by default).
  • TC-R4: Salaried=N, Score=740, Default=N -> Reject.

Rule Simplification & Coverage

After initial table creation, simplify without losing behavioral coverage.

Simplification checks
  • Remove impossible rules (contradictory conditions).
  • Merge rules with same action using don't-care conditions.
  • Keep high-risk exception rules explicit (override or legal mandates).
Coverage checklist
  1. Every remaining rule has at least one test.
  2. Every action appears in at least one test.
  3. Priority/override conditions are tested directly.
  4. Error messages or fallback actions are verified.

Common Mistakes

Missing override rule
Teams forget precedence logic and approve cases that should always reject.
Condition wording not atomic
Mixed conditions in one row cause ambiguous rules and poor traceability.
No impossible-rule pruning
Leads to unnecessary tests and confusion during execution.
Action not verified fully
Checks status only, but ignores message, audit log, or side effect.

Class Activity

  1. Choose a feature with 3-4 rule conditions (discount, scholarship, insurance claim, leave approval).
  2. Write atomic condition rows and action rows.
  3. Create complete rule columns and mark impossible ones.
  4. Simplify table and derive one test per rule.
  5. Present 2 risky rules and explain why they need explicit tests.
Evaluation rubric (10 marks)
  • 3 marks: Correct condition/action extraction.
  • 3 marks: Complete and consistent rule table.
  • 2 marks: Effective simplification and pruning.
  • 2 marks: Test mapping and expected outcomes.

Exit Ticket

  1. Why is one test per rule usually enough in a decision-table suite?
  2. What does - (don't care) mean, and when is it safe to use?
  3. Give one example of an override rule from any domain.

Summary & Assignment

Decision tables convert complex rule sets into clear, testable artifacts. They help teams validate completeness, avoid contradictory behavior, and design compact high-value suites.

Assignment: Build a decision table for a real project rule set with at least 3 conditions and 2 actions. Include simplified rules, mapped test cases, and execution evidence for any 5 tests.
Course Home