Root Cause Analysis

Root cause analysis is the identification of the root cause of a defect.

Basic root cause analysis can often be extremely illuminating ­ if 50% of your software defects are directly attributable to poor requirements then you know you need to fix your requirements specification process. On the other hand if all you know is that your customer is unhappy with the quality of the Product then you will have to do a lot of digging to uncover the answer.To perform root cause analysis you need to be able capture the root cause of each defect. This is normally done by providing a field in the defect tracking system in which can be used to classify the cause of each defect (who decides what the root cause is could be a point of contention!).

The defect was caused by an incomplete or ambiguous requirement with the resulting assumption differing from the intended outcome Design Error .

The design differs from the stated requirements or is ambiguous or incomplete resulting in assumptions Code Error.

The code differs from the documented design or requirements or there was a syntactic or structural error introduced during coding.

Test Error: The test as designed was incorrect (deviating from stated requirements or

design) or was executed incorrectly or the resultant output was incorrectly

interpreted by the tester, resulting in a defect “logged in error”.

Configuration: The defect was caused by incorrectly configured environment or data

Existing bug.The defect is existing behavior in the current software (this does not

determine whether or not it is fixed) sub-classifications are also possible, depending on the level of detail you wish to go to. For example, what kind of requirement errors are occurring? Are requirements changing during development? Are they incomplete? Are they incorrect?Once you have this data you can quantify the proportion of defects attributable to each cause.

 32% of defects are attributable to mistakes by the test team, a huge proportion.

While there are obviously issues with requirements, coding and configuration, the
large number of test errors means there are major issues with the accuracy of testing.

While most of these defects will be rejected and closed, a substantial amount of time will
be spent diagnosing and debating them.

This present defects can be further broken down by other defect attributes such as “status” and “severity”. You might find for example that “high” severity defects are attributable to code errors but “low” severity defects are configuration related.

A more complete analysis can be conducted by identifying the root cause (as above) and how the defect was identified. This can either be a classification of the phase in which the defect is identified (design, unit test, system test etc.) or a more detailed analysis of the technique used to discover the defect (walkthrough, code inspection, automated test, etc.)

This then gives you an overall picture of the cause of the defect and how it is detected which helps you determine which of your defect removal strategies are most effective.