Testing decision rules: decision tables, MC/DC and coverage
How to test a decision rule: decision tables, test cases from a truth table, MC/DC with the engine's independence pairs, condition versus decision coverage, mutation testing, and the patterns behind eligibility, access-control and feature-flag rules.
A Boolean rule with five inputs has 32 cases; nobody tests all 32, and nobody should have to. These pages show the techniques that choose the few cases that matter and say what each technique can and cannot promise. Decision tables (the ISTQB Foundation technique) collapse the table into rules. MC/DC, the criterion aerospace software must meet, asks for a pair of cases per input that differ only in that input and flip the result; the engine computes those pairs. Mutation testing asks whether your tests would notice a changed operator.
Every example on these pages is a real rule computed by the engine: the discount rule, the free-shipping rule, the entry rule, the machine interlock, the loan rule. The MC/DC pages show the pairs the engine found for each input, or state that none exists and why.
The pattern pages are for analysts: how eligibility, access-control and feature-flag rules are usually shaped, the exceptions they usually forget, and the tests that catch them.
- Decision table vs truth table: when to use which
A truth table lists every combination of a rule's inputs with the output on each row. A decision table groups those rows into business rules with conditions and actions. - Decision table testing, worked example (ISTQB Foundation 4.2.3 style)
A worked decision-table test design in the style of the ISTQB Foundation syllabus section on decision table testing: three conditions, a free-shipping rule, eight combinations, and the smaller set of… - MC/DC explained: modified condition/decision coverage for Boolean rules
Modified condition/decision coverage asks, for every condition in a Boolean rule, for a pair of test cases that differ only in that condition and produce different outcomes. - MC/DC independence pairs, worked example with the engine’s coverage report
An independence pair for a condition is two scenarios that differ in that condition only and give different outcomes. - MC/DC vs condition coverage vs multiple condition coverage
Condition coverage takes each condition through both values. Multiple condition coverage takes every combination. - Condition coverage vs decision (branch) coverage
Decision coverage asks that the rule's outcome be TRUE in some test and FALSE in another. Condition coverage asks the same of each condition. - Deriving test cases from a truth table without testing every row
A truth table is a complete list of test inputs with expected results; the question is which rows to keep. - Mutation testing for Boolean rules: operator, negation and literal mutants
Mutation testing plants small deliberate bugs in a rule, such as swapping an operator, dropping a negation or replacing a literal, and asks whether the test suite notices. - Regression tests for decision rules that change
When a rule changes, the question is which rows changed with it. - Writing business rules in plain English that translate to logic
A business rule written in plain English should translate to one Boolean formula without a committee. - Eligibility rules: the pattern, the usual exceptions and the tests
Eligibility rules share one shape: a qualifying group, a disqualifier, and a second requirement. - Access control rules: roles, exceptions and the banned-user slip
Access rules combine roles that grant, roles that grant conditionally, and a lock or ban that takes precedence. owner OR admin OR (editor AND NOT locked) is the pattern with four conditions, and the… - Feature flag logic: combining flags without surprises
Feature flags combine an audience, a master switch and a kill switch, and the surprises come from how they combine. - A review checklist for decision rules (for analysts and reviewers)
A checklist for reviewing a decision rule before it ships, written for analysts and reviewers rather than programmers. - Turning a counterexample into a regression test
A counterexample is a complete assignment on which two things that should agree do not. That is also the definition of a good regression test.
Questions
Does the app compute MC/DC coverage?
The app's coverage report measures input-value, gate-output, decision-outcome and input-influence coverage with published denominators, and suggests independence pairs for inputs whose influence your tests have not shown. The pages here use that same computation. The app does not certify MC/DC compliance; it gives you the pairs and the report.
Is coverage the same as correctness?
No, and the pages say so at every turn. A test suite with full coverage and wrong expected values passes a wrong rule. Expected values have to come from the requirement, not from the formula.
Generated from the Tangibool engine, semantics tangibool-semantics/1, engine 1.0.0, build . Every table, map, simplification and verdict on these pages was computed by the Tangibool engine when the site was built, and every claim was re-checked by the same exact checker the app uses. Limits are stated where they apply. © 2026 Foreranger LTD.