QA closes bugs where I work. In most cases, bugs are closed without mentioning any details about the root cause. The only info given is one of the options in our bug tracker, such as "code", "test data", "tester error" etc.
Senior QAs believe that details about root cause should be mentioned by the developers who fix the bug, not QA. I disagree because I believe that QA finding out root cause (even at high level) has the advantages mentioned below. Note that my "Contrived examples" are quite similar to issues which I have seen.
1 - It enables QA to learn more about the system or even business domain.
Contrived example: A search functionality in a web app was not working for one test data. For another test data, it was working. So, was the error in the search engine or something else ? From dev, I learned that indexing would simply fix the error. In the process, i learned about the system and how to trigger indexing.
2 - It improves QA's knowledge & understanding on how bugs can creep in when they/dev can miss some test cases. They can use this knowledge to come up with more robust test cases for other situations.
Contrived example: On a web page, after clicking one button, an api is called. In rare cases, the response from the api gets delayed and the side effect is that other UI elements get disabled. Those UI elements are not related to that api call and should not be disabled if the response is delayed. The dev told me that delayed response caused the issue. Next time, when I do UI testing, I will see if I should simulate delayed api responses or not.
I am not sure if these reasons are compelling enough to make it mandatory for QA to mention root cause details in bugs.
So, should a QA mention details for the root cause for a bug or not ? Please mention the reasons also.