Root cause analysis is one of the key work of a QA tester, which can help in fixing the issue faster. We use logs and Firebug. The request fails and we can say, this request fails, this command fails etc.
But is there a tool or a way by which we can say exactly where the issue resides and what can we do to solve the issue? Or does this come only by experience? Assuming that the tester has a decent knowledge of how the code is designed.
There isn't a "one tool suitable for everything" concept. For example, Firebug won't be of any help to you if you're testing a desktop or a mobile application, or even a web application that only works on IE (given the fact that you mentioned Firebug and not Developer Tools).
Now assuming that you're referring to web applications, again it's not something exact that works for everything. While you can debug to some extent stuff in your browser using Developer Tools (or Firebug) to go deeper into the issue it's getting more complex. Like the web server type that's hosting your application, programming language, databases, etc etc.
One thing that would apply to all are, like you mentioned, the logs. But this usually depends on how much the developers chose to add to the logs for the application. Then you have your web server logs, Event viewer, and why not, even the programming IDE for you to debug the problems (given that you have access to the code repository).
To answer your direct questions: You are correct that there is no universal process to identifying and/or fixing an issue's root cause. But this is obvious (if this task could be truly automated we wouldn't need developers, let alone QA!) so I think maybe you are looking for something like: what can be done to improve the quality and accuracy of root cause analysis? Or, how deep does a root cause analysis need to go to be valuable/sufficient?
Where I work, as part of our root cause analysis template we are required to answer "5 Whys". Or, what are the first five contributing factors to the issue? An example might be:
What I like about this system is that the specificity of your final "Why" is proportional to the complexity of the issue. The above issue is high level and conceptually simple, and so the "Whys" proceed quickly to an equally high level root cause. But when you perform this task on more code heavy issues you will find that the "Whys" quickly become much more low level, which matches how the issue will be addressed.
The "5 Whys" approach also gives the analyzer a clear stopping point (this is important because without a stopping point a QA resource doing a RCA is just a developer fixing a bug - which is inefficient for most teams) In the above example, we could certainly go to "Why(6)" and "Why(7)" if we wanted to (The bills are sitting unopened on Joe's desk -> We fired Joe 6 months ago). But this is probably not necessary. By the time we have reached "Why(5)" we already know what the root cause of the issue is and have a good idea who to escalate to. This works the other way too. Some complex issues will not be nearly as clear by "Why(5)". This is OK, because it serves as an indicator that the analyzer is either out of their depth, or the issue is broad enough in scope that an early hand-off is warranted.
To summarize: Consider a "5 Whys" approach to root cause analysis to constrain the scope of the analysis activity. In my experience this approach provides a deep and targeted analysis of issues which can be readily probed, while minimizing the time an analyzer can spend "spinning their wheels" on issues that turn out not to be easily pinned down.
Note: The "5" in "5 Whys" is not the magic. "5" works well for us, but it is easy to imagine that for other teams or processes "3 Whys" is a more sensible approach.
Note #2: If you do use this system, you must always provide all X "Whys". It is tempting to stop when "Why(4)" is as concrete as, "The for loop has an off-by-one error." But this is a mistake! If we're only a few levels deep in the "Why" stack this means that the causes leading up to the issue were not numerous enough to justify the issue occurring and their may be a process/architecture/whatever improvement available to us. Find the final "Why". For us it is often, "There was no unit test for XYZ."
One of the main purposes of Firebug and other browser developer tools is to debug your website, therefore they already provide tools to do some root cause analysis.
As you say, they help you to get to know that the reason for a failing command is a failing network request. Or they can tell you via a performance analysis that a recursive call to a JavaScript function is taking a lot of time, which makes your page unresponsive.
The connection between issue and reason still needs to be done by yourself. Tools can't draw that conclusion for you. E.g. a tool doesn't know that a JavaScript function you tried to call is within a file, which failed to load. That requires knowledge of the application logic.
Root Cause Analysis i.e. RCA a.k.a Causal Analysis and Resolution (CAR) at some organisations and yes it is definitely a group process to find resolution and cause of not only a bug but it can also be related to any other issue like Regular Build Failures, Large number of Code review defects or UAT bugs etc. It is not only a QA task but it is a team effort, as a Black Box tester, one alone can't tell a reason for an issue and this process usually takes time.
A level of brain storming is also involved in this process and that is absolutely required too. In addition to this 5-Why technique, there are others techniques like 'Fish Bone Structure' . This too helps in determining the cause of issue.
In your case if tester has a decent knowledge of code and design, then yes he can actively participate in this CAR.
Each RCA should be followed by some action items so that same issue doesn't occur again and this is the main purpose or outcome of any RCA i.e. to minimize or eradicate chances of getting same issue in future.
One more technique called 'Pareto Analysis' provides root cause of issues, given all issues have been assigned proper defect cause (like whether it is an issue because of Coding, Requirement, Lack of Review etc.). This might not provide a deeper analysis of the reason but a broader picture is framed by this technique too and based on that team should shift its focus to that area or can have detailed RCA around that reason.
