Why do testers need root cause analysis? I understand what it is but can't fathom how to describe a connection. How does the definition of root cause analysis change in terms of QA?
-
9I guess the counter to that is "Why bother testing if you're not going to fix it? And how do you fix it without figuring out how it happened in the first place?"– corsiKa ♦Commented May 19, 2019 at 20:21
-
9Why does anyone, in any industry, need to understand and solve the actual problem instead of just patching the symptom and hoping for the best?– jonrsharpeCommented May 19, 2019 at 21:20
-
2really? I don't believe you genuinely cannot fathom why it's a good idea to find out why something happened.– EmobeCommented May 20, 2019 at 11:34
-
unboundedness vs boundedness are, analytically speaking,arbitrary.– RIzaaCommented May 20, 2019 at 15:25
4 Answers
When a defect happens, you want to analyse how it happend. So you can decide if you can prevent similar issues in the future. I would use a simple root-cause analysis for that. Maybe you want to involve other stakeholders like users, developers, managers, etc...
I think it is part of the QA role to make sure preventive actions happen, as we
are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures.
As a tester, you are never trying to fix the problem you are looking at. You're looking to fix the systemic problem which affects thousands or millions of units which you will never look at directly.
The "root cause" is the cause which is most likely to be addressable in such a systemic manner, or alternatively, most likely to be dismissable as not being systemic.
Root Cause Analysis enables prevention of problems, by analyzing problems that happened in the past. As a QA focusing on corrective measures of root causes is more effective than simply treating the symptoms of a problem or event which helps us to encounter more issue for same defect under defect clustering & perform effectively when accomplish through a systematic process with conclusions backed up by evidence, usually there are more than one root cause for any problem or event & we should investigate every cause so that the focus of investigation and analysis through problem identification of event occurred.
I can give you an example from automotive embedded projects. Assume you do a hardware-in-the-loop test of an electronic control unit and you assume you found an issue.
Now, theoretically, it is enough to show the expected and real result and reference the test case leading to it.
However, taking into account you had time- and value-continuous hardware signals, being processed by an software running on a hardware which is not synchronous to the test system and 6MB RAM for static variables in the electronic control unit, it requires often a lot of data to root-cause this.
Always recording everything is not feasible, so you have to plan your "measurements" for each test case or even for individual test steps.
Even then, you might have to retry because this would be more recording capacity than your hardware has.
Last is that your test system itself might have an issue, like loose wires.