Decision Table Testing is a black-box technique for testing combinations of CONDITIONS and their resulting ACTIONS. It's ideal for business rules where the output depends on multiple inputs, ensuring all rule combinations are covered.
You build a table with conditions (inputs) as rows, and each column a RULE combining condition values (True/False), with the expected action(s) at the bottom. This systematically covers combinations that if/else logic can miss. For N boolean conditions there are 2^N combinations; you can collapse infeasible/redundant ones. Decision tables shine for eligibility rules, discounts, permissions, and pricing — anywhere multiple factors combine. They turn tangled requirement prose into a clear, complete set of test cases, exposing unspecified combinations. A frequent interview technique for 'complex business logic' questions.
A discount rule (isMember? cartOver100?) becomes a 4-column decision table: member+over100 → 20%, member+under → 10%, non-member+over → 5%, non-member+under → 0% — four clear, complete test cases.
A discount depends on whether the user is a member AND whether the cart exceeds $100. How do you ensure all combinations are tested?