What is Root Cause Analysis?

Introduction:

RCA (Root cause analysis) is a mechanism of analyzing the defects, to identify its cause. We brainstorm, read and dig the defect to identify whether the defect was due to “testing miss”, “development miss” or was a “requirement or designs miss”.

Doing the RCA accurately helps to prevent defects in the later releases or phases. If we find, that a defect was due to design miss, we can review the design documents and can take appropriate measures. Similarly if we find that a defect was due to testing miss, we can review our test cases or metrics, and update it accordingly.

RCA should not be limited only to the testing defects. We can do RCA on production defects as well. Based on the decision of RCA, we can enhance our test bed and include those production tickets as regression test cases to ensure that the defect or similar kinds of defects are not repeated.

How Root Cause Analysis is Done?

There are many factors which provokes the defects to occur

  • Unclear / missing / incorrect requirements
  • Incorrect design
  • Incorrect coding
  • Insufficient testing
  • Environment issues ( Hardware, software or configurations)

These factors should always be kept in mind while kicking off the RCA process.

There is no defined process of doing RCA. It basically starts and proceeds with brainstorming on the defect. The only question which we ask to ourselves while doing RCA is “WHY?”and “WHAT?” We can dig into each phase of the life cycle to track, where the defect actually persists.

Let’s start with the “WHY?” questions, (The list is not limited). You can start from the outer phase and move towards the inner phase of SDLC.

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

  • “WHY” the defect was not caught during sanity test in production?
  • “WHY” the defect was not caught during testing?
  • “WHY” the defect was not caught during test case review?
  • “WHY” the defect was not caught during “design review”?
  • “WHY” the defect was not caught during requirement phase?

The answer to this question, will give you the exact phase, where the defect actually exists. Now once you identify the phase and the reason, comes the “WHAT” part.

“WHAT will you do to avoid this in future?

The answer to this “WHAT” question, if implemented and taken care off, will prevent the same defect or the kind of defect to arise again. Take proper measures to improve the identified process so that the defect or the reason of the defect is not repeated.

Conclusion:

Based on the results of RCA, you can determine which of the phase has problem areas. For example, if you determine most of the RCA of the defects are due to requirement miss, then you can improve the requirement gathering / understanding phase by introducing more reviews or walk-through sessions.

Similarly if you find that mostly defects are due to testing miss, you need to improve the testing process. You can introduce metrics like requirement traceability metrics, test coverage metrics or can keep a check on the review process or any other step which you feel would improve the efficiency of the testing. It is the responsibility of the entire team to sit and analyze the defects, and contribute to the product and process improvement.