What Is Decision Table Testing? How to Build One with Real Examples | Condition Combination Testing + pytest

Decision table testing is a test design technique that organizes multiple conditions and their combinations into a table format to design test cases. It’s especially effective for verifying business rules where multiple conditions interact — login authentication, permission management, and discount logic are classic examples.

Decision tables let you organize all combinations of multiple conditions without gaps or overlaps — eliminating the “we forgot to test that combination” problem at its root.

“When two or more conditions interact, I lose track of which combinations need to be tested” — this is something every QA engineer has experienced.

• Test cases multiply explosively as conditions increase
• It becomes unclear which combinations have and haven’t been tested
• “We never tested that pattern” — missed cases slip through

Decision table testing solves these problems. This article covers everything from the concept to building tables, real examples, and applying them in pytest.

What Is Decision Table Testing?

Decision table testing organizes the relationship between “conditions (inputs)” and “actions (expected results)” in a table format. Because it systematically captures all condition combinations, it’s widely used for testing complex business logic. It’s also known as a “cause-effect table” or “decision table.”

For example, testing a discount process with two conditions — “user type (standard / premium)” and “coupon availability (yes / no)” — a decision table lets you organize all 4 patterns (2×2) without missing a single one.

Decision Table Structure and How to Build One

A decision table consists of two parts: the Conditions section and the Actions section.

Benefits of Decision Tables

• No missed combinations: All patterns are laid out in the table — gaps are impossible to miss
• Eliminates test case oversights: Moves from “testing by feel” to systematic coverage
• Easy team reviews: QA and dev share a common view of the logic in table form
• Converts directly to automation: Feeds straight into pytest’s parametrize

How to Build One — Step by Step

Example ①: Login Processing Decision Table

The most common example — a login process decision table. The two conditions are “Is the username correct?” and “Is the password correct?”

This table clearly produces 4 test cases. Cases 2, 3, and 4 all result in errors — but since the error messages differ (“username not found” vs “wrong password” vs “both wrong”), all three cases should be run separately.

Example ②: Discount Logic Decision Table (3 Conditions)

With 3 conditions the pattern count grows to 8. Here’s an example with “premium membership”, “coupon used”, and “purchase over $30” as conditions that determine a discount rate.

A quick glance reveals that C4 (premium, no coupon, under $30 = 15%) and C5 (non-premium, coupon, over $30 = 15%) produce the same discount rate. Spotting these “same-result cases” and consolidating them to reduce test count is another benefit of decision tables.

Applying Decision Tables to pytest

Test cases designed with a decision table map directly onto pytest’s @pytest.mark.parametrize. Here’s the login process decision table implemented in pytest.

First, set up the login function being tested.

def login(user_id: str, password: str) -> dict:
    """Login function (sample)"""
    VALID_ID = "test_user"
    VALID_PW = "secret_pass"

    if user_id == VALID_ID and password == VALID_PW:
        return {"success": True, "message": "Login successful"}
    elif user_id != VALID_ID:
        return {"success": False, "message": "Username not found"}
    else:
        return {"success": False, "message": "Incorrect password"}

Next, implement all 4 decision table cases directly as parameters.

import pytest

# All 4 decision table cases parametrized directly
@pytest.mark.parametrize("user_id, password, expected_success, expected_msg", [
    # Case 1: correct ID + correct PW → success
    ("test_user",  "secret_pass", True,  "Login successful"),

    # Case 2: correct ID + wrong PW → failure
    ("test_user",  "wrong_pass",  False, "Incorrect password"),

    # Case 3: wrong ID + correct PW → failure
    ("wrong_user", "secret_pass", False, "Username not found"),

    # Case 4: wrong ID + wrong PW → failure
    ("wrong_user", "wrong_pass",  False, "Username not found"),
])
def test_login(user_id, password, expected_success, expected_msg):
    result = login(user_id, password)
    assert result["success"] == expected_success
    assert result["message"] == expected_msg

Sample Execution Output

$ pytest test_login.py -v

========================= test session starts ==========================
collected 4 items

test_login.py::test_login[test_user-secret_pass-True-Login successful]   PASSED [ 25%]
test_login.py::test_login[test_user-wrong_pass-False-Incorrect password] PASSED [ 50%]
test_login.py::test_login[wrong_user-secret_pass-False-Username not found] PASSED [ 75%]
test_login.py::test_login[wrong_user-wrong_pass-False-Username not found]  PASSED [100%]

========================== 4 passed in 0.12s ===========================

⚠️ 4 Common Pitfalls in Decision Table Testing

Here are the mistakes that are easy to make when building decision tables in practice.

FAQ

📋 Summary

Decision tables turn the “combinations you were tracking mentally” into something visible — bringing missed cases close to zero. Start by building a 2–3 condition table for a login process or permission check you already work with. That’s the fastest way to make it click.