What is a decision table in test design, and what does each column represent?
answer
- Rules become countable, prose does not
- Four quadrants, two of them stubs
- Conditions on top, actions below
- Columns are rules, not conditions
- Two to the power of the conditions
basics
~20 sA decision table is a grid whose rows list the conditions of a rule set and the actions they produce. Each column is one rule: one combination of condition outcomes plus the actions it triggers. Each surviving rule becomes one test case.
solid answer
~50 sA decision table lays a knot of business rules out as a grid with four quadrants. The **condition stubs** are the rows naming the questions asked about the input; the **action stubs** are the rows naming the outcomes the system can produce. To the right of each, the **condition entries** and **action entries** are filled in column by column, and each column is one **rule**: a full combination of condition outcomes together with the actions that combination fires. When every condition is binary the untouched table has one column per combination, so *n* conditions give 2^n rules. Test derivation is then mechanical and auditable: take one test case per surviving column, name it after the rule number, and the case's expected result is read straight off the action entries rather than re-derived from prose. The technique earns its keep exactly where a written specification hides cases inside nested sentences.
code
pseudocode · 14 linesconditions = [subscriber, priorityZone, waitOverThreshold]
actions = [applySurge, waiveCancellationFee, useReservePool]
# R1..R8 are the columns of the table, one per combination
R1: Y Y Y -> N Y Y
R2: Y Y N -> N N N
R3: Y N Y -> Y Y N
R4: Y N N -> N N N
R5: N Y Y -> Y N Y
R6: N Y N -> N N N
R7: N N Y -> Y N N
R8: N N N -> N N N
# derivation: one test case per column, expected result = the action entriesgo deeper
Be ready to draw the grid on a whiteboard: conditions as rows on top, actions as rows below, one column per combination. Say the combination count out loud and finish with one test case per column.
An interviewer expects the mechanics: limited-entry versus extended-entry rows, why the column count is the product of the outcome counts, and how the action entries become the expected result rather than something re-derived from prose.
Show you use the table to interrogate the specification. Demonstrate finding the columns the requirement never answered, taking them back to the owner, and naming tests after rule identifiers so a failure points at a line of the specification.
Own the decision of when a table is worth its maintenance cost: which rule sets get one, when a large table should be split into several small ones, and how rule coverage is reported to stakeholders alongside other coverage measures.
## What the technique is for A decision table is a specification-based test design technique for logic that combines several conditions. Prose specifications describe combined rules badly: a paragraph says what happens when a rider is a subscriber, another sentence adds an exception for a priority pickup zone, and a third qualifies both when the predicted wait is long. Nobody reading that prose can tell you how many distinct behaviours it defines, so nobody can tell whether the suite covers them. A decision table converts the prose into a grid that can be counted. ## The four quadrants The classic layout has four regions. - **Condition stubs** — the rows on the left naming each question asked about the input state. Each must be a predicate with a small fixed set of outcomes, usually true/false. - **Condition entries** — the cells to their right, one column per rule, holding that rule's outcome for each condition. - **Action stubs** — the rows on the lower left naming each observable outcome the system may produce. - **Action entries** — the cells to their right saying, for each rule, which actions fire. A table whose condition entries are only yes/no is a **limited-entry** table. If a condition can take more than two outcomes and the cell holds the outcome itself, the table is **extended-entry**; a table with both kinds of rows is **mixed-entry**. The vocabulary matters in an interview because it explains how the column count grows: it is the product of the number of outcomes of every condition, not always a power of two. ## A worked example Take a ride-hailing dispatcher deciding what to do with an incoming trip request. Three conditions: the rider holds an active subscription; the pickup point is inside a priority zone; the predicted wait exceeds the published threshold. Three actions: apply the surge multiplier; waive the cancellation fee; dispatch from the reserve driver pool. Three binary conditions give 2 x 2 x 2 = 8 columns. Written out, the eight columns force eight explicit answers, and that is the point — the specification's prose only ever answered five of them clearly. A 4-person test team going through the table together typically spends the first half of the session arguing about two or three columns nobody had ever decided, which is a defect found before a line of test code exists. ## From rules to test cases Once the table is agreed, derivation is mechanical: 1. Discard columns marked infeasible — combinations the system cannot physically reach — but record why, rather than deleting them silently. 2. For each surviving column, write one test case whose setup establishes that column's condition outcomes. 3. The expected result is the column's action entries, read verbatim. This is the oracle: the thing that says the observed behaviour is wrong. 4. Carry the rule identifier into the test name, so a failing case points back at the exact rule and the exact line of the specification. Coverage is then reportable as a percentage of rules exercised, which is far more meaningful to a stakeholder than a count of test cases. ## Where it fits and where it does not Decision tables are the right tool when several conditions **combine** to produce different outcomes — pricing, eligibility, discounting, routing, authorisation, claim adjudication. They are the wrong tool when behaviour depends on the order of events over time rather than on a snapshot of conditions; ordering is modelled elsewhere. They are also a poor fit when conditions are independent and each simply switches one action on or off, because then the table is large and says nothing the individual rules did not. The usual objection is size. Eight conditions give 256 columns, and no one maintains that by hand. Two answers exist. First, most large tables are actually several small ones: if a group of conditions only ever affects one action, split it into its own table. Second, columns that produce identical actions can be merged, which is the collapsing step done with don't-care entries. ## What interviewers are really testing The question is a screen for whether a candidate can turn ambiguous requirements into a countable set of cases. Strong answers name the quadrants, state the combination count out loud, and finish with the derivation rule of one case per rule. Weak answers describe the table as a way to document tests already written, which inverts the technique: the table is built from the specification, and it is built precisely because it exposes the cases the specification forgot.
- How many rules does an untouched table have if one condition has three possible outcomes and two others are yes/no?Twelve. The column count is the product of the outcome counts of every condition, 3 x 2 x 2, not a power of two. A table with a non-binary condition row is an extended-entry table, and its cells hold the outcome itself rather than a yes or no. Getting this product right is what makes a completeness check possible later.
- What does the table give you that a list of hand-written scenarios does not?A denominator. Because the number of rules is computable from the conditions, you can state coverage as rules exercised over rules that exist, and you can prove a combination was considered and deliberately dropped rather than forgotten. A scenario list has no such property: nothing in it tells you what is missing.
- When would you not reach for a decision table?When behaviour depends on the order of events over time rather than on a snapshot of conditions, or when each condition switches exactly one action independently of the others. In the first case a table cannot express sequence; in the second the table is large and adds nothing over reading the rules one at a time.
It is a truth table with a job: the left half asks every question the rules can ask, and the right half writes down what the system must do for each possible set of answers.
saying these in an interview costs you the question
- Calling each row a rule instead of each column
- Building the table from existing tests rather than the specification
- Treating the table as documentation, not a source of cases
- Assuming every table has exactly two columns per condition
- Reading the expected result from the code under test
- Skipping combinations the prose never mentioned