Bug Reports - Five major issues

Right through my carrier so far, I have seen a lot of hot negotiations between the testers and the developers and that too for Bug Reports. I have fired a lot of bugs in my carrier (professional + personal) and still firing. Some of my all time favorite bugs are spectacular crashes. They are fun to watch and rewarding to find.

If there is a critical bug in released software, one of the two things happened:

Either no one found the bug before release or
Someone found the bug but no one fixed it before release.

None of us likes it when bugs in the first category bite us, but it’s the bug in the second category that hurt the most. There are some reasons that insist this second category. Using this article, I will try to summarize some points that should be taken care before firing the bug reports.

Test team is supposed to file (or I will say “fire”) bugs in the Bugs Tracking System. But normally I have seen that the Bug Report submitted by the tester is not clear and do not give a clear picture of what went wrong while testing. There are some points that should be mentioned clearly in the bug report. And also there are some things that we should ignore while reporting a bug against the product.

Presenting a list of five major problems that is quite common in the Bug reports.

1. Testers do not describe how to reproduce the bug. Either no procedure is given, or the given procedure doesn't work. Either case will likely get the bug report shelved. There should be an exact set of test steps which should clearly convey to the development team that what are the steps to reproduce the bug. Ideally, a tester should try to reproduce the issue thrice and then make a consolidated list of steps to reproduce. That will help the development team to understand the issue in a better way and they will easily reproduce that bug without even taking help with the testing team. When I started my carrier as a tester, no one was able to understand the bug report that I was sending. But gradually, I understood that how important is the clarity of the report for the whole team.

2. They don't explain what went wrong. At what point in the procedure does the bug occur? What should happen there? What actually happened? These are more or less related to the point above. While mentioning the steps to reproduce in the bug report, it should be clearly mentioned that at what step or at what point, the bug enters in the test case execution. It’s better to explain ideally what should happen at that particular step or how the application should handle the scenario at that time. Actual output and expected output should be clearly mentioned. As I said before, I also got this mania in my initial 2 years of testing experience.

3. They are not persuasive about the priority of the bug. Your job is to have the seriousness of the bug accurately assessed. There's a natural tendency for programmers and managers to rate bugs as less serious than they are. If you believe a bug is serious, explain why a customer would view it the way you do. If you found the bug with an odd case, take the time to reproduce it with a more obviously common or compelling case. As a tester, you should assign carefully “priority of fixing” of that bug.

4. They do not help the programmer in debugging. This is a simple cost/benefit tradeoff. A small amount of time spent simplifying the procedure for reproducing the bug or exploring the various ways it could occur may save a great deal of programmer time. Try to dig out the issue and concentrate on “Root Cause Analysis (RCA)” of the Bug. It’s better to raise an issue and simultaneously try to analyze the RCA of that bug. If you have any observation regarding this, you should add it on the bug report. This will definitely help the developers to resolve the issue quickly. I used to mention the detailed observation of the bug and try to dig the issue as far as I can perform. But please don’t forget to add your observations in the Bug Report.

5. They are insulting, so they poison the relationship between developers and testers. A smooth working relationship between developers and testers is essential for efficient testing. As a test team member, you are always a “Bad News Reader”. So we should be polite and diplomatic while writing a bug report. In my 6 years of work experience in testing, I have seen that 80% of time, development team and testing team discusses about the bugs. Or I can say fighting on the issues.

So take care of these points and try to develop a healthy rivalry between the developers and testers. Clarifying the problem can take you a long way toward solving it.

-- Sanat Sharma