What is Decision Table Testing?

Decision table testing is a black-box test design technique that maps combinations of input conditions to expected actions in a table, ensuring every meaningful combination of conditions is tested systematically rather than by guesswork.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

When behavior depends on several conditions interacting, ad-hoc testing easily misses combinations. A decision table makes them explicit: conditions are listed as rows at the top, each column is a unique combination (a "rule") of those conditions, and the resulting actions or outcomes are the rows at the bottom. With N boolean conditions there are up to 2^N combinations, and the table forces you to consider each.

For example, a discount might depend on "is a member?", "order over $100?", and "has a coupon?". A decision table lays out all eight combinations and the expected discount for each, immediately revealing combinations the developer (and the spec) may have overlooked. In practice you often collapse impossible or equivalent combinations to keep the table manageable.

Decision table testing pairs naturally with equivalence partitioning and boundary value analysis, and it is especially valuable for business-rules-heavy logic (pricing, eligibility, permissions). It is a staple of the ISTQB syllabus and a common interview technique question.

WHY IT MATTERS

Why interviewers ask about this.

Decision table testing is a named test-design technique interviewers expect QA candidates to know. Describing how it systematically covers combinations of conditions, and when to use it (complex business rules), demonstrates structured test design.

EXAMPLE

Example scenario.

A loan-approval feature depends on credit score, income, and existing debt. A decision table enumerates the combinations and their expected outcomes, surfacing a rule nobody specified: high income but high debt. Testing that overlooked combination reveals the system wrongly approves it.

TIP

Interview tip.

Explain the structure (conditions as rows, each column a combination/rule, actions at the bottom) and say it is for logic driven by multiple interacting conditions. Mention collapsing impossible combinations and pairing it with equivalence partitioning.

FAQ

Frequently asked questions.

When should you use decision table testing?

Use it when behavior depends on combinations of multiple conditions, business rules like pricing, eligibility, discounts, or permissions. The table forces you to consider every meaningful combination instead of guessing.

How many test cases does a decision table produce?

With N independent boolean conditions there are up to 2^N combinations (columns). In practice you collapse impossible or equivalent combinations to keep the number of test cases manageable while preserving coverage.