Decision Tables for Rule-Based Scenarios

What a Decision Table Is (and When to Use It)

A decision table is a compact way to model rule-based behavior when multiple conditions combine to produce different outcomes. Instead of writing many separate scenarios in prose, you list the conditions that matter, enumerate meaningful combinations, and define the expected action for each combination (each “rule”).

Use a decision table when:

• More than one input/condition affects the result (e.g., eligibility + thresholds + flags).
• Rules overlap and it’s easy to miss combinations.
• You need to prove coverage of business rules, not just “happy paths.”

A decision table helps you answer: “Have we tested every relevant combination of conditions, and do we know the expected outcome for each?”

Core Parts of a Decision Table

Conditions

Conditions are the factors that influence the outcome. Each condition has a small set of possible states (often Yes/No, or a few categories like Low/Medium/High).

Actions (Outcomes)

Actions are what the system should do for a given combination of condition states, such as “Apply 10% discount” or “Reject coupon.”

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Rules

Each column (or row, depending on layout) represents one rule: a specific combination of condition states paired with expected actions.

Step-by-Step: Building a Decision Table

Step 1: Extract conditions and actions from the rule text

Read the business rule and underline: (1) decision factors (conditions), (2) outcomes (actions), and (3) constraints (impossible combinations or precedence rules).

Step 2: Normalize condition states

Convert each condition into a small, testable set of states. Avoid raw numbers when possible; use categories that match the rule language (e.g., “Cart value < 50” vs “Cart value ≥ 50”).

Step 3: Enumerate combinations

Start with the full cross-product of condition states. For three Yes/No conditions, that’s 2 × 2 × 2 = 8 combinations. For mixed states, multiply counts (e.g., 2 × 3 × 2 = 12).

Step 4: Remove impossible or irrelevant combinations

Eliminate combinations that cannot occur in the real system (e.g., “Coupon valid = Yes” while “Coupon entered = No”). Also remove combinations explicitly excluded by the rules.

Step 5: Add expected actions for each remaining rule

For each valid combination, define the expected outcome. If multiple actions can occur, list them all (e.g., “Apply membership discount” and “Show message”).

Step 6: Turn each rule into a test case

Each rule becomes a test case (or a small set of test cases if multiple data examples are needed). Your test case should clearly state preconditions (condition states) and expected result (actions).

Full Worked Example: Discounts Based on Membership + Cart Value + Coupon Validity

Business rules (written form)

• Membership discount: Members get 10% off when cart subtotal is at least $50; otherwise 5% off.
• Non-members get no membership discount.
• Coupons: If a coupon is entered and valid, apply an additional 5% off.
• If a coupon is entered and invalid, do not apply coupon discount and show message “Coupon invalid.”
• Maximum total discount is 20% (cap after combining discounts).

Step 1–2: Identify conditions and states

Conditions (with normalized states):

• C1: Customer is a member? (Yes/No)
• C2: Cart subtotal at least $50? (Yes/No)
• C3: Coupon status (None / Valid / Invalid)

Actions (outcomes):

• A1: Apply membership discount (0% / 5% / 10%)
• A2: Apply coupon discount (0% / 5%)
• A3: Show message (None / “Coupon invalid.”)
• A4: Total discount percentage (capped at 20%)

Step 3: Enumerate combinations

There are 2 × 2 × 3 = 12 combinations.

Step 4–5: Fill the decision table and expected actions

All 12 combinations are possible here (coupon can be none/valid/invalid regardless of membership and cart value). Now define the expected actions for each rule.

Decision Table: Discounts (Membership + Cart Value + Coupon Status)

Conditions                          R1   R2   R3   R4   R5   R6   R7   R8   R9   R10  R11  R12

C1 Member?                          Y    Y    Y    Y    Y    Y    N    N    N    N    N    N

C2 Subtotal ≥ $50?                  Y    Y    Y    N    N    N    Y    Y    Y    N    N    N

C3 Coupon status                    None Valid Invalid None Valid Invalid None Valid Invalid None Valid Invalid

Actions

A1 Membership discount %            10   10   10   5    5    5    0    0    0    0    0    0

A2 Coupon discount %                0    5    0    0    5    0    0    5    0    0    5    0

A3 Message                          -    -    Invalid -    -    Invalid -    -    Invalid -    -    Invalid

A4 Total discount % (cap 20%)       10   15   10   5    10   5    0    5    0    0    5    0

Note on the cap: In these rules, the maximum combined discount is 10% + 5% = 15%, so the 20% cap never triggers. This is still useful to note: you can decide whether to add a separate rule set later if new discounts could exceed 20%.

Turning Each Rule into a Test Case

Below is how to convert rules into test cases with clear preconditions and expected results. The goal is to keep each test case tied to one decision-table column.

Example test case derived from R2

Test Case ID: DT-DISCOUNT-R2

Preconditions:

• Customer is a member.
• Cart subtotal is $50 or more (e.g., $80).
• Coupon status is Valid (a valid coupon code is entered).

Steps:

• Open cart/checkout with the member account.
• Ensure subtotal is at least $50.
• Enter the valid coupon code and apply.

Expected result:

• Membership discount applied: 10%.
• Coupon discount applied: 5%.
• No error message shown.
• Total discount shown/applied: 15% (and not capped further).

Example test case derived from R6 (invalid coupon path)

Test Case ID: DT-DISCOUNT-R6

Preconditions:

• Customer is a member.
• Cart subtotal is below $50 (e.g., $30).
• Coupon status is Invalid (an invalid/expired coupon code is entered).

Steps:

• Open cart/checkout with the member account.
• Ensure subtotal is below $50.
• Enter an invalid coupon code and apply.

Expected result:

• Membership discount applied: 5%.
• Coupon discount applied: 0%.
• Message displayed: “Coupon invalid.”
• Total discount shown/applied: 5%.

Quick mapping guide (all rules to test cases)

You can generate one test case per rule (R1–R12). The preconditions come directly from C1–C3, and the expected results come from A1–A4.

• R1: Member, ≥$50, no coupon → total 10%
• R2: Member, ≥$50, valid coupon → total 15%
• R3: Member, ≥$50, invalid coupon → total 10% + invalid message
• R4: Member, <$50, no coupon → total 5%
• R5: Member, <$50, valid coupon → total 10%
• R6: Member, <$50, invalid coupon → total 5% + invalid message
• R7: Non-member, ≥$50, no coupon → total 0%
• R8: Non-member, ≥$50, valid coupon → total 5%
• R9: Non-member, ≥$50, invalid coupon → total 0% + invalid message
• R10: Non-member, <$50, no coupon → total 0%
• R11: Non-member, <$50, valid coupon → total 5%
• R12: Non-member, <$50, invalid coupon → total 0% + invalid message

How to Remove Impossible States (Mini-Example)

Sometimes you’ll define conditions that create combinations that cannot happen. Here is a common pattern: separating “Coupon entered?” from “Coupon valid?”

If you model:

• C3: Coupon entered? (Yes/No)
• C4: Coupon valid? (Yes/No)

Then the combination “Coupon entered = No” and “Coupon valid = Yes” is impossible and should be removed from the table. This pruning step prevents you from writing meaningless test cases.

Practice: Build a Decision Table and Extract Test Cases

Practice rule set

You are testing shipping fee rules for an online store:

• Standard shipping base fee is $8.
• If cart subtotal is at least $60, standard shipping is free.
• Premium members always get free standard shipping, regardless of subtotal.
• Oversized items add a $12 surcharge to shipping (even if base shipping is free).
• If the delivery address is a PO box, oversized items cannot be shipped; show message “Oversized items cannot ship to PO boxes.” and do not allow checkout.

Your tasks

• List conditions and define their states (keep them small and rule-focused).
• Enumerate combinations and remove impossible ones.
• For each remaining rule, define actions: shipping fee amount, whether checkout is allowed, and any message.
• Extract test cases: one per rule, with preconditions and expected result.

Suggested starting point (conditions)

• C1: Premium member? (Yes/No)
• C2: Subtotal ≥ $60? (Yes/No)
• C3: Oversized item in cart? (Yes/No)
• C4: Address is PO box? (Yes/No)

Hints for pruning and actions

• Identify the “blocking” rule: Oversized + PO box should result in checkout not allowed, regardless of other conditions.
• When base shipping becomes free (by membership or subtotal), the oversized surcharge may still apply.
• Define actions clearly, for example: A1 Shipping fee = 0 / 8 / 12 / 20, A2 Checkout allowed = Yes/No, A3 Message = None / specific text.

Template you can copy

Conditions                  R1 R2 R3 R4 R5 R6 R7 R8 ...

C1 Premium member?          

C2 Subtotal ≥ $60?          

C3 Oversized item?          

C4 PO box address?          

Actions

A1 Shipping fee ($)         

A2 Checkout allowed?        

A3 Message