Root cause Analysis known as RCA is the process of analysing any problem/issue or defect to identify the main reason or cause behind it. In Software Testing this technique is used to identify the root cause of bugs raised by QA or Client.

We all know defect found in the early stage in SDLC will be at lower cost than defect found in later stage. Approximately, cost of fixing a defect in the testing phase is up to 10 times more than if you catch it in the requirement or design stage right at the start. The cost to fix that same defect in a post-release product is up to 30 times more. So, if we can identify the cause of defects, which we get in the testing phase, then there can be possibilities to avoid those issues. A very popular and effective process – an answer to this challenge is the Root Cause Analysis (RCA).In Root cause analysis we,brainstorm, read and dig the defect to identify whether the defect was due to “Testing miss”, “Development miss” or was a “Requirement or design miss”.

Why we should do RCA?

  • To identify the cause of the problem.
  • Fix/Solution for the problem so that we can prevent the defects from reoccurring.
  • It enables the management to think of ways to continually provide improvements

Now we know what RCA and its importance is. Let’s figure out few basic principles of RCA:

Make the aim of Root Cause Analysis to determine how to fix a problem and other related problems.

  • Use Root Cause Analysis in a systematic way.
  • Remember a problem can have more than one root cause.
  • Keep cost in mind when determining a fix to a problem.
  • Keep in mind a fix needs to be sustained.
  • Understand that Root Cause Analysis can cause a change to a culture and resistance from those who will implement the change.
  • It is not necessary that RCA can be done only on defects, bugs, it can also be done on any problem related to Process, manpower or infrastructure etc.

We can have different scenario where causes can occur:

  1. Safety-based root cause analysis– Its origin can be mainly being found in accident , safety and healthcare.
  2. Production-based root cause analysis– Its origin can be mainly being found in quality control and industrial manufacturing.
  3. Process-based root cause analysis– This is the follow-up from production and business processes.
  4. Failure-based root cause analysis– Its origin can be found in Engineering and maintenance.
  5. Systems-based root cause analysis– its origin can be found in the amalgamation of the approaches mentioned above and this is combined with ideas from change management, risk management and systems analysis.

The basic process consists of 6 steps. These corrective measures will lead to the true cause of the problem.

Step 1: Identify the problem:

Find out the problem you have. For eg: Food Quality is not good.

Step 2: Define the problem:

Find out What do you see happening?

In defining a problem, we need to state the problem or elaborate it. I have taken a problem from our day to day life. I am sure, many of us can related to this problem of Power cut in our homes or areas.

Step 3: Collect the data:

You need to analyse a situation fully before you can move on to look at factors that contributed to the problem. We need to find out the proof of the problem exists and impact of the problem:

Step 4: Categorize the Problem:

The categories of the problem can be related to People, environment, Infrastructure, process etc.

Step 5: find out the cause:

In this step we should find out the cause of the problem related to those categories. We should know: What is the reason for the problem to occur?

Step 6: Take improvement measurements:

In this step we should find out the ways to correct or the ways in which we could have avoided the problems. List down all the possible ways.

Step 7: Implement the solution:

This will be the final step for RCA where you need to implement the solution you have found to avoid the similar kind of the problem in future.

Let me explain the above problem with a diagram:

Please zoom your browser to view the diagram clearer.

Techniques of Root cause analysis:

Fish bone diagram

5 Whys

Tree diagram



Fish bone Diagram

The above example is of Fish bone diagram which is also known as Ishikawa. It’s an analysis tool that provides a systematic way of looking at effects and the causes that create or contribute to those effects. Because of the function of the fishbone diagram, it may be referred to as a cause-and-effect diagram. The various causes are grouped into categories, with arrows in the image indicating how the causes flow toward the nonconformity. Categories used in the fishbone diagram are not pre-defined, but common categories include equipment, processes or methods, measurements, materials, environment, and people. This type of root cause analysis is a causal process and seeks to understand the possible causes by asking questions such as “what actually happened,” “when.

Let’s see another prebuilt example. This example is taken from internet:

Please zoom your browser to view the diagram clearer.

5 Why?

This is another technique to find Root cause analysis which helps team quickly get the causes of the issues where they can take the measures. In this exercise team members contribute in explaining the issues and what could be possible reason of those problems.

The 5 Whys is a technique used in the Analyse phase of the Six Sigma DMAIC (Define, Measure, Analyse, Improve, Control) methodology. … By repeatedly asking the question “Why” (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem.

Process of 5 Why

  • Get a team and write down the problem.
  • Ask the first WHY for the problem to team. Note is down. There can be possible 3-4 answers, record them all.
  • Drill down the further WHY for the same issues

Let me share an practical example for 5 why :

In this example we can figure out a common solution:

Solution: Proper analysis of the system in each stage and Detailed KT or requirement document.

In fact, each why can have a solution associated to it if required.

Let’s take another example from Google:

Tree Diagram:

Tree diagrams allow us to see all the possible outcomes of an event and calculate their probability. Each branch in a tree diagram represents a possible outcome. If two events are independent, the outcome of one has no effect on the outcome of the other.


It is a process in which a group quickly generates as many ideas as it can on a problem. Brainstorming is useful because it uses the collective brainpower of the group to generate many ideas. Guidelines for conducting a successful brainstorming session are:

  • Collect a mixed team representing all parts of the process
  • All ideas are welcome no matter how silly it is. Be creative. The more idea the better points and solutions will be.
  • Don’t criticise or judge others.
  • Set a time for brainstorming. Don’t allow it to go out of context.
  • Have impartial facilitator conduct the session. The facilitator should not lead the session, but keep it moving and prevent value judgements from being made
  • Assign two people to write ideas down on a flip chart or white board so that all ideas are captured
  • Go for quantity rather than quality of ideas; ideas can be ranked later
  • No judgements – every idea is a good idea
  • Stop the session after sufficient ideas have been gathered
  • Go for quantity rather than quality of ideas; ideas can be ranked later
  • No judgements – every idea is a good idea
  • Stop the session after sufficient ideas have been gathered


It is another method to represents the issue in graphical format. Flow chart gives the clear picture of the issues and reason of it. It is very much important to keep the flow chart simple and clear. Here we follow the basic method of creating flow chart which includes rectangles for process step, arrow for direction and diamond for decision.

Pareto Analysis — A statistical technique in decision making that is used for analysis of selected and a limited number of tasks that produce significant overall effect. The premise is that 80% of problems are produced by a few critical causes (20%).I will be explaining Pareto Analysis on the separate blog post in detail.

The main aim of RCA is to find where problems originated and then remove those problems. We can have business benefits and increase customer satisfaction by tracking defects and user feedback. With RCA, we can boost the quality of the software for our end users.

Suggestions and comments are welcome.Please hit like below the post and subscribe to my site.Keep learning and growing and stay tuned for more blogs.