Root-Cause Analysis in Defect Tracking

As the name suggests, a defect tracking software lets you keep track of defects in a database. An efficient tool maps well to your development and quality processes – one that supports bug prioritization and assignment to particular developers. Most tools also provide search and filter options that help you create targeted bugs. Report generation is also a common feature that displays graphs and pie charts to better analyze the results.

There is a wide variety of defect tracking software in the market. On one hand, there are open-source tools that allow customization like Bugzilla and on the other hand, there are commercial packages that provide excellent and flexible defect tracking capabilities that come with support and optionally secure hosting – one example of such software is JIRA by Atlassian.

Root-Cause Analysis

For organizations, having bug management tools is important to maintain medium- to large-scale systems. While there’s no denying their usefulness, this software merely records the process through which a defect report goes. They don’t address the crucial question of “why the problem occurred”. To find that out, organizations conduct root-cause analysis that determines the earliest point in the design and implementation of a program in which the defect was introduced.

Doing a root-cause analysis is important for several reasons.

• It keeps you from fixing symptoms
• It enables you to improve the quality evaluation methods for the phase in which the defect was introduced
• It makes it easier to find similar bugs sooner in the future

However, programmers are unwilling to record this information because when managers look to downsize programmers, they may base their decision on false conclusions derived from root-cause analysis data. In this case, they might terminate or withhold raises from programmers who have the most root-cause records logged against software they worked on.  

Both of these choices are irrational because there may be other reasons than programmer incompetence. Uneven test coverage can also make one part of a system appear more defective than others, which may not be true. Withholding raises from the programmer who submits the most records may also mean discouraging the most diligent tester in his group.

Keeping this in mind, most organizations promise not to keep individual records, but statistical summaries of the information. Meaning that the root-cause information is aggregated with totals, averages, counts, and so forth, as soon as the programmer enters the information. Managers can’t evaluate the work of individuals, they can only see trends. 

As a database of root-cause analysis records is developed, the ability to focus a debugging search on the most frequent errors increases. This database recalls fixed problems that were similar to the problems that are currently being worked on. This enables teams to diagnose more quickly and thereby fix more defects. Statistical summary of analysis can point out areas where improvement is required in terms of skills or defensive programming tactics to avoid the problem in the future.