Decision Table Testing (Example)

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Decision Table Testing is a black-box technique that captures input combinations and their expected outputs in a tabular form. This tutorial explains the cause-effect concept, walks through login and upload examples, and shows why the method delivers strong coverage for complex business logic.

  • 🧮 Core Idea: A decision table maps conditions (causes) to outcomes (effects) for systematic coverage.
  • 🔢 Combination Rule: The number of rules equals 2 raised to the number of conditions (2^n).
  • 🔐 Worked Examples: Login and photo-upload screens show True/False conditions mapped to outputs.
  • ✅ Best Use: Ideal when system behavior differs for each input combination.
  • 🤖 AI Enablement: AI tools now generate decision tables from requirements and prune redundant rules.
Read More

Decision Table Testing

What is Decision Table Testing?

Decision table testing is a software testing technique used to test system behavior for different input combinations. It is a systematic approach in which the different input combinations and their corresponding system behavior (output) are captured in a tabular form. That is why it is also called a Cause-Effect table, where causes and effects are recorded for better test coverage.

A Decision Table is a tabular representation of inputs versus rules, cases, or test conditions. It is a highly effective tool for both complex software testing and requirements management. A decision table helps check all possible combinations of conditions, and testers can easily identify missing conditions. Conditions are indicated using True (T) and False (F) values.

Example 1: Decision Table for a Login Screen

Let us create a decision table for a login screen.

Decision Base Table for Login Screen

The condition is simple: if the user provides the correct username and password, they are redirected to the homepage. If any input is wrong, an error message is displayed.

Conditions Rule 1 Rule 2 Rule 3 Rule 4
Username (T/F) F T F T
Password (T/F) F F T T
Output (E/H) E E E H

Legend:

  • T – Correct username/password
  • F – Wrong username/password
  • E – Error message is displayed
  • H – Home screen is displayed

Interpretation:

  • Case 1 – Username and password both wrong. The user is shown an error message.
  • Case 2 – Username correct, password wrong. The user is shown an error message.
  • Case 3 – Username wrong, password correct. The user is shown an error message.
  • Case 4 – Username and password both correct. The user navigates to the homepage.

When converting this to a test case, you can create two scenarios, because the three error cases all test the same rule.

  • Enter the correct username and correct password, then click Login — the user should navigate to the homepage.
  • Enter a wrong username and/or wrong password, then click Login — the user should see an error message.

Example 2: Decision Table for an Upload Screen

Now consider a dialog box that asks the user to upload a photo under certain conditions:

  1. Only the “.jpg” format is allowed.
  2. File size must be less than 32 KB.
  3. Resolution must be 137 × 177.

If any condition fails, the system throws a corresponding error message; if all conditions are met, the photo uploads successfully.

Decision Table for Upload Screen

The decision table for this case is shown below.

Conditions Case 1 Case 2 Case 3 Case 4 Case 5 Case 6 Case 7 Case 8
Format .jpg .jpg .jpg .jpg Not .jpg Not .jpg Not .jpg Not .jpg
Size < 32 KB < 32 KB ≥ 32 KB ≥ 32 KB < 32 KB < 32 KB ≥ 32 KB ≥ 32 KB
Resolution 137×177 Not 137×177 137×177 Not 137×177 137×177 Not 137×177 137×177 Not 137×177
Output Photo uploaded Resolution mismatch Size mismatch Size & resolution mismatch Format mismatch Format & resolution mismatch Format & size mismatch Format, size & resolution mismatch

From this table, you can create eight test cases for complete coverage:

  1. .jpg, < 32 KB, 137×177 → photo uploads successfully.
  2. .jpg, < 32 KB, not 137×177 → resolution-mismatch error.
  3. .jpg, ≥ 32 KB, 137×177 → size-mismatch error.
  4. .jpg, ≥ 32 KB, not 137×177 → size and resolution mismatch error.
  5. Not .jpg, < 32 KB, 137×177 → format-mismatch error.
  6. Not .jpg, < 32 KB, not 137×177 → format and resolution mismatch error.
  7. Not .jpg, ≥ 32 KB, 137×177 → format and size mismatch error.
  8. Not .jpg, ≥ 32 KB, not 137×177 → format, size, and resolution mismatch error.

Why Decision Table Testing is Important

Decision table testing is important because it tests many combinations of conditions and provides strong coverage for complex business logic. When system behavior differs for each set of inputs, the technique gives good coverage in a simple, easy-to-read representation.

In software engineering, boundary value analysis and equivalence partitioning are similar techniques, but they are most effective when the system shows the same behavior across a large set of inputs. When the behavior is different for each input combination, those techniques cannot ensure good coverage — and decision table testing becomes the better option.

This table also serves as a reference for requirements and functionality development because it is easy to understand and covers all combinations. The significance grows as inputs increase: the number of possible combinations is 2^n, where n is the number of inputs. For n = 10, which is common in web forms, that is 1,024 combinations. You cannot test all of them, but you can select a rich subset using decision-based testing.

RELATED ARTICLES

Advantages of Decision Table Testing

  • Works when system behavior differs across inputs, where equivalence partitioning and boundary value analysis fall short.
  • The representation is simple, so it is easily interpreted and useful for both development and business teams.
  • Helps build effective combinations and ensures better test coverage.
  • Any complex business condition can be turned into a decision table.
  • Can ensure 100% coverage when the number of input combinations is low.

Disadvantages of Decision Table Testing

The main disadvantage is that as the number of inputs increases, the table becomes more complex and harder to manage.

FAQs

Decision table testing is a black-box technique that captures combinations of input conditions and their expected outputs in a table. It ensures systematic coverage of complex business rules.

It maps causes (input conditions) to effects (system outputs). Capturing both sides in one table makes the relationship explicit, which is why it is also known as a cause-effect table.

The number of rules equals 2^n, where n is the number of binary conditions. For example, 4 conditions produce 16 rules, and 10 conditions produce 1,024 possible combinations.

Boundary value analysis suits inputs where behavior is the same across a range. Decision tables suit cases where each input combination produces a different output, providing coverage the other techniques miss.

Use it when a feature has multiple input conditions that interact to produce different outputs, such as login validation, form uploads, or pricing and discount rules with several dependencies.

As the number of conditions grows, the table expands exponentially (2^n) and becomes hard to manage. Testers usually select a representative subset of rules rather than testing every combination.

AI tools read requirements and generate decision tables automatically, identify missing or redundant rules, and collapse equivalent rules. This reduces manual effort while improving combination coverage.

Yes. AI can convert each rule in a decision table into a concrete test case with inputs and expected results, then prioritize them by risk so high-impact combinations are tested first.

Summarize this post with: