ISTQB does not distinct between these (it reads "Branch/decision coverage") but some sources do say it is different. I would have two question. The essential one is about the difference. And the other one - does this whole concept belongs under the unit testing? Or white box testing? Thanks

From the ISTQB:

branch coverage is closely related to decision coverage and at 100% coverage they give exactly the same results. Decision coverage measures the coverage of conditional branches; branch coverage measures the coverage of both conditional and unconditional branches. The Syllabus uses decision coverage, as it is the source of the branches. Some coverage measurement tools may talk about branch coverage when they actually mean decision coverage. (c) ISTQB foundation book.


4 Answers 4


The branch is an optional execution path, whereas a decision is the result of a combination of conditions (i.e. a boolean expression).

Thus, there can be decisions without branches.

For example:

int fun(int a, int b) {
   return (a > 5) && (b < 15);

In the above function, (a > 5) is a condition, (b < 15)" is another condition. (a > 5) && (b < 15) is a decision. And there is no branch.

Thus in this example, the decision coverage will be reached with only 2 tests, and the branch coverage on source code reach 100% with a single test.

Branch coverage at the assembly level would require the same two tests, but the question becomes tricky if you write the function like this:

int fun(int a, int b) {
   return (a > 5) & (b < 15);

There is still a boolean decision (computed with arithmetic operations) and the assembly would not have branches.

NASA's handbook on MCDC measurement clarifies this type of difference: https://ntrs.nasa.gov/citations/20010057789

  • Thanks for the answer. And thanks for the link to NASA paper. Jun 15, 2017 at 21:00
  • I don't agree that there is no branches. Actually there are of course two in this case. The first is return true if the decision is satisfied otherwise return false Sep 28, 2020 at 17:45
  • The above link seems to be not working. But this one does - ntrs.nasa.gov/citations/20010057789 Dec 31, 2020 at 10:45
  • +1 for the nice resource link for MCDC handbook.
    – Cem Polat
    Oct 13, 2023 at 9:40

Here's the problem in a nutshell:

if ((test1() || test2()) {
else {

Suppose you have two test cases:

  • test1() evaluates to true, and
  • Both test1() and test2() evaluate to false.

Some code coverage tools will yield 100% coverage because these two test cases result in the execution of every statement. The problem is that every path has not been tested. This code needs three test cases, one more for the case where test1() evaluates to false but test2() evaluates to true.

In this hypothetical example, that third critical test case would expose that latent bug. If you fail to provide that third case and use a coverage tool based solely on statement executions you will get a false sense that testing is complete.

  • 2
    so whats the difference?
    – Leprechaun
    Jul 7, 2017 at 18:27
  • great answer but incomplete Sep 26, 2017 at 8:13

If you think about your program as a big directed graph with a start node going to one or more end nodes. Each statement in your program is a node on the graph, branches or decisions are edges between nodes.

Full statement coverage is when you visit every node in the graph at least once, full branch/decision coverage is when you traverse every edge in the graph at least once (and I think they are the same thing).

Neither of these is necessarily the same as Full path coverage, when you traverse every path from the start node to every end node.

As with any terminology there is no guarantee that everyone means exactly the same thing by the same term. Wikipedia seems to take branch coverage to mean modified decision coverage but there are plenty of other sources, as you note, that say they are the same. What we can say more authoritatively is that statement coverage is not the same as branch coverage, and neither are the same as path coverage.

If you need to use these terms then your best bet is to define what you mean by them before you use them.

For point 2. Coverage metrics can be used on any form of testing, it is certainly fairly common to use it on unit tests and on automated system/integration tests

  • But you have said branch/decision while they are not the same thing (according to e.g. Wikipedia). That is what I am asking.
    – John V
    Jan 25, 2013 at 13:02
  • 1
    I can imagine a[n admittedly poorly designed] system where there are two edges from one statement to the next. In such a case, if one traverses only one edge then they have statement coverage but not branch coverage. They may be functionally the same (in most cases, at least) but there is a distinction.
    – acattle
    Jan 25, 2013 at 13:02
  • this is essentially an issue of descriptive terminology. some people define BC and DC as the same thing some people define BC and DC as slightly different things. They are essentially BOTH right.
    – jk.
    Jan 25, 2013 at 14:15
  • I have updated the question so the difference is visible there.
    – John V
    Jan 25, 2013 at 14:25
  • If you want to use that as a definition that is fine, use that. Just be aware that many people will use the two terms interchangeably. Given that definition usually come from use rather than authority both are correct as I have said.
    – jk.
    Jan 25, 2013 at 14:30

branch coverage is like doing TRUE and FALSE, but in decision coverage, you need to go through each condition ...

for example:

if( (a>5) || (b>6) ) {statments...} else {statments...}

in this scenario for branch coverage, you need to simply make if condition true than false as well

TC1: a>5 OR b>6

TC2: a<5 and b<6

but for the decision coverage, u need to consider the boolean table and need to satisfy each of the conditions...


1 a<5 b<6 FALSE

2 a<5 b>6 TRUE

3 a>5 b<6 TRUE

4 a>5 b>6 TRUE

  • 1
    No, that is the condition coverage. By definition, a decision is made up of boolean conditions.
    – John V
    Nov 18, 2019 at 9:46
  • Notwithstanding the down votes, this is quite correct - or at least to the avionics industry... edited to try to retrieve it!
    – Andrew
    Jun 4, 2020 at 11:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.