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. Neither shows that a condition matters, and the alarm rule below is small enough to see why in eight rows.
The rule is armed AND (door OR window): the alarm sounds when the system is armed and a door or a window is opened. Decision coverage is met by two tests, one that sounds the alarm and one that does not. Condition coverage is met by two tests that take armed, door and window through both values, for example all-TRUE and all-FALSE, which also happen to satisfy decision coverage. Neither pair of tests says anything about the window.
The engine's independence pairs do. For armed: door = FALSE, window = TRUE with the system disarmed (silent) against armed (alarm). For door: armed with both closed (silent) against door open (alarm). For window: armed with both closed (silent) against window open (alarm). Three pairs, four scenarios, and now each condition has been shown to change the outcome on its own, which is MC/DC.
The weaker criteria are not useless; they are cheap first checks. The point is what they do not promise: a window sensor wired to nothing passes both, and a suite designed to the stronger criterion is the one that notices. The pattern pages on alarms and access control, and the lesson on test design, reuse this rule.
Example
alarm := armed AND (door OR window) · output
Exact checks
Truth table (8 rows)
| # | armed | door | window | alarm |
|---|---|---|---|---|
| 0 | FALSE | FALSE | FALSE | FALSE |
| 1 | FALSE | FALSE | TRUE | FALSE |
| 2 | FALSE | TRUE | FALSE | FALSE |
| 3 | FALSE | TRUE | TRUE | FALSE |
| 4 | TRUE | FALSE | FALSE | FALSE |
| 5 | TRUE | FALSE | TRUE | TRUE |
| 6 | TRUE | TRUE | FALSE | TRUE |
| 7 | TRUE | TRUE | TRUE | TRUE |
Plain-language reading
Beginneralarm is true exactly when both of the following hold:
1. armed is true
2. at least one of door or window is true (both may be true)
In every other case, alarm is false.
About the operators:
- AND is true only when all of its parts are true.
- OR is inclusive: it is true when at least one part is true, including when several are.
Intermediatealarm is true exactly when both of the following hold:
1. armed is true
2. at least one of door or window is true (both may be true)
In every other case, alarm is false.
Advancedalarm is true exactly when both of the following hold [conjunction ∧]:
1. armed is true
2. at least one of door or window is true (both may be true) [inclusive disjunction ∨]
In every other case, alarm is false.
Formal notation: armed ∧ (door ∨ window)
Logic diagram
MC/DC
| Input | Status | Independence pair (only that input changes) |
|---|---|---|
| armed | found | armed=F, door=F, window=T → F | armed=T, door=F, window=T → T |
| door | found | armed=T, door=F, window=F → F | armed=T, door=T, window=F → T |
| window | found | armed=T, door=F, window=F → F | armed=T, door=F, window=T → T |
The common slip
Taking “every condition was TRUE and FALSE in some test” as evidence that every condition was tested. It is evidence that the values occurred, not that they mattered; the window can be TRUE in a test where the door was already open and change nothing.
Questions
Is decision coverage the same as branch coverage?
For a rule with one outcome, yes: the decision is the branch. Structural branch coverage of code adds every if and loop; the rule's decision is one of them.
How many tests do the three criteria need here?
Decision: two. Condition: two. MC/DC: four, from the three pairs that share the armed-both-closed scenario. The full table has eight.
Related
Practice
See also
- MC/DC vs condition coverage vs multiple condition coverage
- MC/DC explained: modified condition/decision coverage for Boolean rules
- Decision coverage in software testing: meaning and examples
- Condition coverage in software testing: meaning and examples
- MC/DC (modified condition/decision coverage): meaning and examples
- Alarm rule: armed AND (door OR window OR motion) AND NOT disarm_code
- Lesson 12: Designing tests that find bugs (advanced, 15 min)
Testing and rules
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.