Q
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

What role should automated testing play?

Get ready -- the role of software tester is changing

Can this brand new tester's job be saved?

This was last published in August 2016

Dig Deeper on Agile DevOps

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How is root cause analysis useful in your organization?
Cancel
Agile teams do retrospectives - not quite only the root cause analysis of the problems. Noticing what goes well is no less important.

As for defect root cause analysis, it's tricky. Unless we have a systemic problem, why not just fix and move on?
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close