Home > Uncategorized > I Hate Bug Reports

I Hate Bug Reports

I hate bug reports not because I have an ego and I think I write excellent code which can never have bugs or that I don’t want to fix them but because they often leave crucial information to reproduce the bug and/or what was the expected result and why the results are wrong and I end up in a wild goose chase hunting the testers for answers.

If the tester is not reporting the bug correctly, the developer will most likely reject this bug stating as not reproducible and assign it back the tester. The tester would most probably argue that the bug is there and it can be reproduced and a whole mess ensnares where the developer and tester both end up kicking the ball back and forth at each other. Not only is this time lost in non productivity but it gets pretty frustrating pretty fast.

If you want a bug to be fixed you need to report the bug effectively. So here are just a few pointers to our testers:

  • The bug title should describe the issue completely. Bug title will help developers to quickly analyze the bug nature. It saves time when we don’t need to open the whole bug report to know what the problem is. Keep in mind bug title is used as a reference to search the bug in the bug tracking tool so add in any keywords in the title which you think might help in finding the bug.
  • If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug in the minimalist steps possible. Developers need to be able to get to the problem in the shortest time. Do not assume or skip any reproducing step. Always step through the steps yourself and make sure you don’t leave a step. Make sure your steps are robust enough to reproduce the bug without any ambiguity. Don’t assume that the developers can read your mind – don’t assume that they will do a few extra steps you think are obvious.
  • Never include more than one issue per report. If you have multiple issues, post separate bug reports for each and mark them as related. Reporting multiple bugs in one report will most likely cause your report to be closed when only part of it is implemented.
  • Do not post new bug or feature requests about the same bug or feature. Doing so takes a lot of time for us to merge your reports. The search feature of the bug tracking system is everyone’s friend.
  • Report the problem immediately. If you find any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.
  • To create the highest quality bug report which will save developers time and increase the likelihood the bug is fixed, a little extra work goes a long way:
    • Is the bug tied to a single setting or is there a small range of cases? Identify the range.
    • What other user actions cause the error to occur?
    • Does the error occur with different settings or options selected?
  • Attachments are extremely helpful
    • Screenshots with comments really help understand the problem. A picture is worth 1000 words.
    • At the same time a picture should not be there to replace reproduce steps. The bug should still be captured in text even if a screenshot is attached.
  • A bug report should always contain the expected and observed results. Often times the developers don’t think that the bug is a real bug so it helps to explicitly list the expected and observed results. It is the testers duty to explain to the developers what went wrong.
  • Don’t use the bug report as a stepping stone – we have enough politics in the office already.

No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

Oh and one final note; just because the system performs differently that what was expected does not necessarily mean it is a bug. Remember "The best tester is the one who gets the most bugs fixed" – Cem Kaner

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: