Do testers always have to provide root-cause analysis? No, they don’t need to and, in fact, all depends on a particular case. Every single testing activity is different from another and there are priorities you have to deal with as project resources are never limitless. There may be small features that don’t require that effort and dedication and there are large features that is quite vital to the product, root-cause analysis may be required.
However root-cause analysis is, indeed, a great thing, you should at least give it a try and here is why: it grants you with more information and data is pure power in a tester’s arms. After root-cause analysis testers do understand the feature under test in a significantly better manner. You can locate so many new marvelous things like critical areas you have never tested and you will gain additional scope during the analysis. And, surely, there will be more bugs for you to track.
Why isn't everybody doing it then?
This process is time consuming and not all projects are capable or willing to spend more additional resources on such tasks, especially if they are low-priority and the release cycles are very short. There are even times where some team members already know what hides in the root-cause making this activity useless.
How can I tell whether any root-cause analysis should be performed?
There are several factors, by measuring which you will be certain on whether the root-cause analysis activity is something you and your project can afford.
First of all take a deep look at the defect. Is it worth is?
Secondly go through your current test coverage as well as your test plan to make sure if you need this additional work in the first place.
Then review defect priority to make sure if it requires additional attention and take a good look at your team/team members: are they up for more work helping you? Do they have time? Is it really necessary?
And if all the mentioned above factors are satisfying you should go for root-cause analysis.
No comments:
Post a Comment