Statement Coverage vs Branch Coverage
The short answer
Statement coverage counts the executable statements your tests have run; branch coverage counts the transfers of control your tests have taken - which is the stronger criterion, because 100% branch coverage always delivers 100% statement coverage while the reverse is not true.
These are the two white-box criteria in the Foundation syllabus, and the exam almost always tests them together, in one question, by asking for the minimum number of test cases each would need for the same fragment of code. Getting that right depends on one idea: the criteria are nested, not parallel.
There is also a version trap. CTFL v3.1 taught decision coverage; v4.0 replaced it with branch coverage, and the two are not synonyms. A branch is any transfer of control between two nodes, which includes unconditional transfers in straight-line code and not only the outcomes of a decision. Material written for v3.1 - which is still most of what ranks for this query - will tell you a branch is a decision outcome, and on a v4.0 paper that is the distractor.
Side by side
| Statement coverage | Branch coverage | |
|---|---|---|
| What is counted | Executable statements exercised | Branches exercised - transfers of control between nodes |
| Coverage formula | Statements exercised divided by total executable statements | Branches exercised divided by total branches |
| Includes unconditional transfers | Not applicable | Yes - a branch need not come from a decision |
| Subsumption | Weaker - does not imply branch coverage | Stronger - always implies 100% statement coverage |
| if (a > 0) { doSomething(); } finish(); | 1 test case - run it with a > 0 | 2 test cases - the true and the false outcome |
| Can 100% leave a transfer untaken | Yes - an if with no else leaves the false transfer untaken | No, for the branches themselves |
| CTFL v3.1 name | Statement testing and coverage - unchanged | Decision testing and coverage - renamed and redefined in v4.0 |
How to work the minimum test case question
The classic question gives you a short fragment and asks for both minimums at once. This procedure gets it right without drawing a control flow graph.
- 1Count the executable statements and ask what the fewest paths are that touch all of them. That is your statement coverage answer.
- 2Find every decision. Each one needs both its true and its false outcome taken, whether or not the code has an else.
- 3An if with no else is the trap. Its statements are all reached by the true case alone, so statement coverage needs one test - but the false transfer still exists and branch coverage needs a second.
- 4Sanity-check the relationship before you answer. Branch coverage can never need fewer test cases than statement coverage. If your two numbers say otherwise you have miscounted, and the option that inverts them is on the paper for exactly that reason.
- 5Remember 100% branch coverage gives you 100% statement coverage for free. If an option claims full branch coverage with statements left unexecuted, it is wrong by definition.
Why branch coverage is the stronger criterion
The subsumption relationship is worth stating precisely, because the exam words it carefully. Any set of test cases that achieves 100% branch coverage also achieves 100% statement coverage. The converse does not hold: a test suite can execute every statement in a program and still leave branches untaken. That asymmetry is the single most examined fact about these two criteria.
It follows that branch coverage is the more demanding target and that reporting it is more informative. It does not follow that 100% branch coverage means the code is correct. Coverage measures what your tests exercised, not whether the behaviour they exercised was right - and the syllabus is careful here: if the software does not implement one or more requirements, white-box testing may not detect the resulting defects of omission, because there is no code for the missing feature to leave unexercised.
Both are white-box criteria, which means they are derived from the structure of the code rather than from the specification. That is what puts them in a different family from equivalence partitioning and boundary value analysis, and it is why a question about deriving tests from a requirement is never a coverage question, however much arithmetic it contains.
Worked exam questions on white-box testing
The answer and the reasoning are shown in full, including why each wrong option is wrong. These are drawn from the questions-and-answers page, so working them here does not spend the unseen pool the practice drills draw from.
1. What is the MINIMUM number of test cases for 100% statement coverage and for 100% branch coverage respectively?
K3if (a > 0) { doSomething(); } finish();- A.2 and 2
- B.1 and 2
- C.2 and 1
- D.1 and 1
Correct answer: B
One test with a > 0 executes every statement. Branch coverage additionally needs the false outcome, so it requires two.
2. What is the MAIN value of white-box testing that black-box testing cannot provide?
K2- A.It can be performed before the code exists
- B.It removes the need for black-box testing
- C.It measures coverage of the code that was actually written, including code the specification never mentioned
- D.It guarantees the absence of defects in the code
Correct answer: C
Because it works from the implementation, white-box testing can expose code that no specification-derived test would reach.
Test your knowledge with real ISTQB-style questions
You’ve learned Statement Coverage vs Branch Coverage. Now sit a full 40-question paper and see if it holds up under the clock.
Or read questions with worked answers, or take a chapter-only practice drill.