Bug Reporting
Finding bug is not a big deal, to get a bug fixed is a really tough for a tester. Bug reports are the primary work product of most testers. The better your reports, the better your reputation. Programmers rely on your reports for vital information. Good reporting of good bugs earns you a good reputation. You are not usually present when your bug report is received and read. When you write a bug report, you are asking a programmer to do some more work. Much bug fixing is done on their time - after hours or on weekends. You are asking them to give this time up for the bug you found. To get a bug fixed, you have to convince the Change Control Board to approve the fix or programmer to fix it on his own (when board isn’t looking). Because so many people read and rely on bug reports, take the time to make each report informative and understandable. Keep clear the difference between severity and priority. Severity refers to the impact of the bug. Priority indicates when your company wants it fixed. Severity doesn’t change unless you learn more about hidden consequences. Priorities change as a project progresses. Always report non-repoducible errors, they may be time bombs. Sometimes the program misbehaves in the way that you can’t replicate. You see the failure once, but don’t know how to get it again. If that happens to a customer, it will erode confidence in the product. When you report a non reproducible bug, make it clear that you cannot replicate the bug. Some tracking systems have a field fir this (can you reproduce the bog: yes/no/unknown). Using Print Screen, video recording can help you prove the existence of error. When you are told that one of the bugs you reported has been fixed, test it as soon as you can. Giving prompt attention to verify fixes shows respect to the programmer and makes it more likely that he will respond quickly to your bug reports in future. Bug reports should be closed by tester, when a bug has been marked as resolved, a tester should review it. If the bug report was rejected as non reproducible or not understandable, the tester should fix the report. If the bug was rejected as a non bug, the tester should decide whether to gather additional data in order to challenge the rejection. No bug should be marked as closed unless it has been reviewed and closed by the tester.