vege - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

How should I handle root cause analysis in software testing?

It's important to take finding the root cause of a defect seriously in an Agile team using continuous improvement. Expert Amy Reichert explains how she narrows it down.

Doing root cause analysis in software testing is a common practice for Agile teams using continuous improvement....

Root cause is also used to measure risk within the functions of an application. If one section of the code generates more defects than another -- and that code is used at a higher rate -- then the risk is greater that a defect will affect the application's performance.

It's important to have an accurate definition of parameters to ensure a valid root cause determination. Any team member setting the value for the root cause must understand the definition of the parameters and use it consistently. For example, a software development group may have a tool that lists these generic types of options to select for root cause: 

  • Requirements
  • Design
  • Code
  • User Error
  • Design

To perform accurate root cause analysis in software testing, everyone needs to understand the definition of the selections and what they cover. For example, if I set the root cause to requirements, I mean that the defect was not defined or discovered due to poor acceptance criteria or vague requirements. Personally, I find I set a lot of root cause values as requirements. What about design? If there's no design specification, it's difficult to pin it on the design. In my mind, design is part of requirements or an integral part thereof.  

We know defects occur because the code has errors. Errors get there in many ways and for various reasons. I rarely use this option unless it's server or memory-type error that could have been caught with a unit test or quick manual test. 

Setting a root cause as a user error is dangerous territory. Is it a good idea to blame the user internally or externally? Never. This type of value is not useful because if it was simply user error, the defect wouldn't have been fixed, making this option illogical.

Every team member doing root cause analysis in software testing may define or view the root causes differently. It's important that all team members share the same definition when setting the root cause value or the metrics generated from it aren't useful. 

After all, the purpose of determining root is providing data to improve software development processes.  The development team and the customer gain value only when the data is accurate and consistent.

Next Steps

Get ready -- the role of software tester is changing

Can this brand new tester's job be saved?

The root cause analysis process needs all IT hands on deck

Dig Deeper on Code refactoring and management