It's not necessary for QA to do root-cause analysis for every defect they found. It's up to circumstances. And for the level of drill-down, I did not drill to the level of source-code when I tested a Unix binary application. But I did html/css root-cause analysis when I tested a website. As a view of user I represent, I access only the information that a user can access.
It's good for a QA to do root-cause analysis - I back it. More information provided helps developer to fix it faster. Tester has more understanding about the system under test. Tester could find the critical area that never tested or discover additional test scope during analysis. And tester who do analysis might have the solution for that defect!
But in another point of view, yes, it takes a lot of time and might affect the overall test project. Tester might take time to find nothing helpful or someone in the team knows the root-cause already. So it's important to encourage tester to keep the balance.
If I take care of a testing project, I will encourage tester/QA to consider the following circumstances:
- Defect Description
- Test Coverage & Test Progress against Test Plan
- Defect Priority & Defect Severity
- Team Availability
How?
- Defect Description First of all, when tester found a defect, then should take time to have enough information; environment, replication
steps to allow them to recreate the defect.
- Test Coverage & Test Progress against Test Plan If the high priority test cases have been tested and the progress is good against test plan, tester could do further analysis for a defect. But if there are high priority or critical test cases outstanding, tester should take time to continue test that area more than root-cause analysis a defect.
- Defect Priority & Defect Severity If a defect have high severity such as system crash with simple steps or high priority defect such as it affects more of the user. tester should take time to analysis to make it fix as soon as possible.
- Team Availability If developer is busy with another issue and tester is available, it's good to take this time to investigate the issue before submit all information you get to the developer.
The last important I will mention here is communication. When you work in a team, before you take ( or will take ) a lot of time on any issue - communicate to team to see if they have any concern. You will have a good balance.
Hope it helps, :)