Doing root cause analysis in software testing is a common practice for Agile teams using continuous improvement....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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:
- User Error
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.
What role should automated testing play?
Get ready -- the role of software tester is changing
Can this brand new tester's job be saved?
Dig Deeper on Agile DevOps
Related Q&A from Amy Reichert
QA needs to keep reminding business of its value. Expert Amy Reichert offers tried-and-true advice on how to leverage documentation and automation to...continue reading
Contract QA jobs can pay more than staff positions, but only if you're a good negotiator. Expert Amy Reichert helps explain the differences between ...continue reading
Quality assurance professionals need to start thinking about bringing business along for the ride. Expert Amy Reichert offers tried-and-true advice ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.