Otdfbt

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?

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.

moderntesting.org

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.