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.


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

Thus, there can be decision without branch. 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 assembly level would require the same two tests, but the question become 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 handbook on MCDC measurement clarify this type of differences. http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20040086014_2004090420.pdf

| improve this answer | |
  • Thanks for the answer. And thanks for the link to NASA paper. – Stanislav Pankevich Jun 15 '17 at 21:00

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.

| improve this answer | |
  • 1
    so whats the difference? – Leprechaun Jul 7 '17 at 18:27
  • great answer but incomplete – cozyconemotel Sep 26 '17 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

| improve this answer | |
  • 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 '13 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 '13 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 '13 at 14:15
  • I have updated the question so the difference is visible there. – John V Jan 25 '13 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 '13 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

| improve this answer | |
  • No, that is the condition coverage. By definition, a decision is made up of boolean conditions. – John V Nov 18 '19 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 at 11:17

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