Equivalence classes and boundary values work well when the result depends on a single value. But often it depends on a combination of conditions: a discount is calculated differently depending on whether the customer is new, whether they paid by card, and whether the order exceeds a certain amount. For this, other techniques are needed — decision tables and pairwise testing.
Both techniques solve the same problem: there can be a very large number of combinations, and you need to figure out carefully which ones to check so that nothing important is missed without drowning in the process.
Decision table: if-then rules
A decision table is a way of writing out all conditions and results in a table so you can clearly see every combination. It's indispensable when the requirements contain logic of the form "if this and that, then do so."
Example. Discount rule: "new customers get 10%; paying by card adds another 5%." There are two conditions (new customer? paid by card?), each with two values (yes/no). Total combinations: 2 × 2 = 4:
| New customer? | Paid by card? | Discount |
|---|---|---|
| Yes | Yes | 15% |
| Yes | No | 10% |
| No | Yes | 5% |
| No | No | 0% |
Now you have four clear test cases and no combination is forgotten. Often it's exactly while building such a table that a question surfaces that the requirements don't answer: "do the discounts stack, or does the larger one win?" That's valuable — you found a gap in the requirements before testing even started.
When there are too many combinations
With two or three conditions the table is small. But combinations grow explosively. Five conditions with two values each is already 32 combinations. Add a field with four options — hundreds. Testing all of them by hand is impossible, and most of the combinations wouldn't reveal anything new anyway.
Example: a form runs in 3 browsers, on 3 operating systems, for 3 user roles. The total number of combinations is 3 × 3 × 3 = 27. Running all 27 is slow and mostly pointless.
Pairwise testing
Pairwise testing is based on a practical observation: most bugs are caused not by some exotic combination of five conditions at once, but by the interaction of some one pair of values. For example, "Safari + admin role" — and that's the bug, regardless of the operating system.
The idea of pairwise: select a small set of checks such that every pair of values appears at least once. Those 27 combinations from the example then shrink to roughly 9 — while coverage of all pairs is preserved. The number of bugs caught stays nearly the same.
Nobody calculates these sets by hand — there are free online tools and generators for this (search for "pairwise tool"): you enter the parameters and their values and get a ready-made compact list of combinations. Your job is to understand why this matters and know how to apply it when the number of combinations gets out of hand.
How to choose a technique
A simple rule:
- Few conditions (two or three), and all the if-then logic matters → decision table, test all combinations.
- Many conditions/parameters, and an exhaustive check is unrealistic → pairwise testing, compress down to a manageable set.
Where this applies
These techniques come up wherever behavior depends on several "switches": pricing and discounts, role-based access rights, settings, combinations of "browser + device + account type." As soon as you catch yourself thinking "there are too many options here, I can't check them all" — that's the signal to reach for a decision table or pairwise testing.
Where beginners stumble:
- Trying to check all combinations by hand and burning out, or giving up halfway through and testing random ones.
- Checking only one or two obvious combinations and missing the exact pair where the bug lives.
- Not building a table for if-then logic and ending up missing an entire combination of conditions.
What to learn next. Not everything needs formal test cases and tables — sometimes a checklist is faster and more convenient. And any check needs the right test data — that's what the next article is about.