Branch and Decision Coverage

Why it matters

Statement coverage, the subject of the previous lesson, cannot see an outcome that skips code: once the statements inside an if have run, it never asks what happens when they are skipped. Many defects live exactly there: a wrong default kept when the if is not taken, a missing else, an input that a guard such as if (qty > 0) should filter out but no test ever sends. Branch coverage forces a test through each of these outcomes.

For a tester, each uncovered outcome is a concrete question: what should happen for a non-member, an empty cart, an unknown status? The answer becomes a test with an expected result from the requirement, or reveals a defect or a missing requirement.

Decisions and their outcomes

A decision is a point where the code chooses which statement runs next; each possible choice is a decision outcome. Decision coverage is the decision outcomes exercised divided by all decision outcomes, as a percentage. Start by finding every decision; some are easy to overlook:

• if, with or without else: two outcomes. Without an else, the false outcome skips the block and has no statement of its own.
• The conditional operator a ? b : c: two outcomes inside one statement, so statement and line coverage count it as covered even if one side never ran.
• Loops (for, while): enter the body or leave. A test that runs the body once takes both outcomes, so zero iterations are never required.
• switch: one outcome per case, plus the default outcome, even when no default clause is written.
• if (a && b) is one decision with two outcomes; the conditions inside it are the subject of the next lesson.
• Dense or minified code hides decisions: format it first so that each statement, including each if and loop, sits on its own line, then look inside expressions for ?:.

Try it: JavaScript Formatter

Branch coverage and how it relates to decision coverage

The ISTQB Foundation syllabus v4.0 teaches branch testing. A branch is a transfer of control between two nodes of the control flow graph, the diagram of the orders in which statements can run, whose nodes are statements or blocks of statements: unconditional for straight-line code, conditional when it is a decision outcome. Branch coverage is the branches exercised divided by all branches, as a percentage.

Because the two criteria count different things, their percentages can differ below 100%, but in ordinary code the same tests reach 100% on both: once every decision outcome has run, every block after it has run too. Many teams use the names as synonyms; syllabus v3.1 taught decision coverage, and v4.0 replaced it with branch coverage.

• Coverage tools report "branches" and mostly mean decision outcomes; coverage.py measures them when run with --branch.
• Tools differ in what they count: some also count each operand of && and ||, or each jump in compiled code. Compare percentages only from the same tool.

Why 100% branch coverage includes 100% statement coverage

Every executable statement is the end of at least one branch: control reaches it from the entry of the function, from the statement before it, or through a decision outcome. If your tests have taken every branch, control has arrived at every statement, so every statement has run. That is why the syllabus says branch coverage subsumes statement coverage: any test set reaching 100% branch coverage also reaches 100% statement coverage.

The reverse does not hold. The false outcome of an if without else contains no statement, so tests can run every statement without ever taking it.

• Subsumption is about 100% only. Below that, either percentage can be the higher one: a test that takes only the true side of an if without else can score 100% of the statements and 50% of the decision outcomes, while a test that takes only the short side of an if/else whose other side is long scores 50% of the decision outcomes and a much smaller share of the statements.
• Stronger is not sufficient: 100% branch coverage says nothing about combinations of outcomes, data-dependent defects such as a zero divisor, or code that was never written.

Worked example: a discount nobody asked for

Requirement: "Members get 20% off the price. Non-members pay the full price. Orders under 200.00 SAR after the discount pay 25.00 SAR shipping; orders of 200.00 SAR or more ship free." The code below has 8 executable statements and two decisions, on lines 3 and 8: 4 decision outcomes.

• T1 checkout(100, true) expects 80 + 25 = 105 and passes. It runs all 8 statements (100% statement coverage) but takes only the true outcome of each decision: 2 of 4, 50% decision coverage.
• Missing: line 3 false (a non-member) and line 8 false (a total of 200.00 or more). One test takes both: T2 checkout(300, false), expecting 300.
• T2 fails: the code returns 270, because line 2 starts every customer at 10% off, a default the requirement never mentions. Non-members get a discount they are not entitled to, and some of their orders just above 200.00 lose free shipping.
• With T1 and T2, decision coverage is 100%. A team that stopped at 100% statement coverage after T1 would have released the defect.
• Any value on each side satisfies the criterion; boundary value analysis adds totals of 199.99 and 200.00 to check the <. After the fix, rerun them all as confirmation testing.

 1  function checkout(price: number, member: boolean): number {
 2    let discountPercent = 10;
 3    if (member) {
 4      discountPercent = 20;
 5    }
 6    const total = price - (price * discountPercent) / 100;
 7    let shipping = 0;
 8    if (total < 200) {
 9      shipping = 25;
10    }
11    return total + shipping;
12  }

Test                        Expected  Actual  Result  Outcomes taken
T1  checkout(100, true)     105       105     passed  line 3 true,  line 8 true
T2  checkout(300, false)    300       270     failed  line 3 false, line 8 false

Coverage    Statements    Decision outcomes   Not taken
T1          8/8  100%     2/4   50%           line 3 false, line 8 false
T1 + T2     8/8  100%     4/4  100%           none

Try it: Boundary Value Generator Try it: Test Case Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• NIST SP 500-235: Structured Testing: A Testing Methodology Using the Cyclomatic Complexity MetricNIST · 1996Structured (basis path) testing: McCabe's cyclomatic complexity used to derive a basis set of independent paths to test — more thorough than statement and branch coverage.