# What is Cyclomatic Complexity – Learn with an Example

Cyclomatic Complexity is a very common buzz word in the Development community. This technique is mainly used to determine the complexity of a piece of code or functionality.

The technique was developed by MaCabe and helps to identify the below 3 questions for the programs / features

• Is the feature / program testable?
• Is the feature/ program understood by every one?
• Is the feature / program reliable enough?

As a QA we can use this technique to identify the “level” of our testing. It is a practice that if the result of cyclomatic complexity is more or a bigger number, we consider that piece of functionality to be of complex nature and hence we conclude as a tester; that the piece of code / functionality requires an in-depth testing. On the other hand if the result of the Cyclomatic Complexity is a smaller number, we conclude as QA that the functionality is of less complexity and decide the scope accordingly.

Let me go step by step: first understand how is it calculated, and then we will move on to understand how the level of testing is determined.

### How to Calculate Cyclomatic Complexity?

The calculation of CC revolves around 2 concepts

1. Nodes
2. Edges

Statements in a program are represented as nodes, and control paths from one statement to another are represented by Edges.

### Cyclomatic Complexity formula

The formula for calculating CC is as:

CC = E~N+2

Where:

E= Number of edges

N= Number of nodes.

(There is a shortcut for calculating it, but not now……later…)

### Cyclomatic Complexity Example

Lets take the below example to understand it.

Consider the below Control flow graph:

I have placed the RED dots to identify the Nodes and BLUE lines to identify the edges:

So here in this example:

Number of Nodes (Red dots) = 14

Number of Edges (Blue Lines) = 15

So the Cyclomatic Complexity = N~E+2 = (14-15) +2 = 3

### How can Testers use it?

In real world, Testers can sit with developers to derive the control flow graph for a given piece of code. And once we have the graph, we can derive the complexity using this formula. But the story for Testers does not end here: – the main point here is – what is the use of this number for the testing team?

Well, Testers can make use of this number to determine the level of their testing. In practice there are 2 levels of testing:-

1. Length Testing

Consider the below matrix for different features of any module:-

------------

Length Testing is a way by which we try to cover the entire scope by selecting the important test cases for each feature. For example in this case suppose I select to imply with the Length testing, then I may select –

• Sub feature 1.1 and Sub Feature 1.3 for Feature 1
• Sub feature 2.2 from Feature 2
• Sub Feature 3.3 from Feature 3
• Sub Feature 4.2 and Sub Feature 4.3from Feature 4
• Sub Feature 5.3 from Feature 5

So here I am touching upon the entire feature without going into exhaustive details of sub features.

Now if the result of the CC is a bigger number then I choose to go with Breadth testing, I will be actually testing each and every feature along with each and every sub feature.

So based on your current project requirement, environment dependability, testers can collaborate together with the development team and create a standard for identification of the level and scope of testing. For example –

• If the CC <=15 – Basic sanity test
• If the CC is between 16 and 30 – Length Testing
• If the CC is between 31 and 50 – Breadth testing
• If the CC >50 – It’s a chaotic functionality and needs further decomposition

### Now comes the shortcut-

Just count the number of closed region and add 1 to it.

In our example above – number of closed region = 2(filled in yellow), so the CC = 2+1 = 3

In the real work it’s very difficult to conclude the result when we give statements like –

• “…..this functionality is very difficult to implement”

What do you mean by difficult? Is it complex, complicated or chaotic?

How did you conclude that this is difficult?

• “…this should be available by end of day”

What is end of the day? Your end of the day is 7.00 pm, probably mine is 6.00 pm?

• “…I would need to do detailed testing for this”

What is detailed testing? There is no testing technique called “Detailed Testing”

• “…the code should be of good quality before we deploy it to QA”

How do you measure good quality?

Instead, If I rephrase the statements like –

The Cyclomatic Complexity for the piece of code is calculated as 75 and as per our standards; this functionality is of Chaos nature. Hence we recommend further decomposing it.

Over

• “…..this functionality is very difficult to implement”

The functionality will be deployed in QA environment by 5.00 PM CST.

Over

• “….this should be available by end of day”

Since the Cyclomatic complexity is calculated as 48, as per our standard we would be doing the systems testing along with the Integration and Regression testing for the feature.

Over

• “….I would need to do detailed testing for this”

As per Sonar, the CC is now 102. We have standardized to have the CC to 10. We will be deploying the code when we improve the code to make the CC less than 10.

Over

• “….the code should be of good quality before we deploy it to QA”

What is the difference in the two statements?

Well, the difference here is measurement. I have supported each of my statement with appropriate measurement which would help my stakeholders to know exactly what I want to say.

Similarly use Cyclomatic complexity in software testing to determine the exact measure of your testing efforts and you can use it to not only identify scope of your testing but also the types of testing which you would need to do.