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:
- 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 Code refactoring and management
Related Q&A from Amy Reichert
QA needs to reiterate its value to the business side of the organization. Use this tried-and-true advice to leverage documentation and automation to ... Continue Reading
Vendors have inched toward automated application testing for a long time, yet there is still room for growth. Software tester Amy Reichert offers her... Continue Reading
Whether you want to discover new software testing methodologies or rejuvenate test cases, QA is all about efficiency. Evaluate these testing ... Continue Reading