Chapter 38. How to Use a Bug Tracker

Matt Doar

image with no caption

WHETHER YOU CALL THEM bugs, defects, or even design side effects, there is no getting away from them. Knowing how to submit a good bug report, as well as what to look for in one, are key skills for keeping a project moving along nicely.

A good bug report needs to convey three things:

  • How to reproduce the bug, as precisely as possible, and how often this will make the bug appear

  • What should have happened, at least in your opinion

  • What actually happened, or at least as much information as you have recorded

The amount and quality of information reported in a bug says as much about the reporter as it does about the bug. Angry, terse bugs (“This function sucks!”) tell the developers that you were having a bad time, but not much else. A bug with plenty of context to make it easier to reproduce earns the respect of everyone, even if it stops a release.

Bugs are like a conversation, with all the history right there in front of everyone. Don’t blame others or deny the bug’s very existence. Instead, ask for more information or consider what you could have missed.

Changing the status of a bug—e.g., Open to Closed—is a public statement of what you think of the bug. Taking the time to explain why you think the bug should be closed will save tedious hours spent later on justifying it to frustrated managers and customers. Changing the priority ...

Get 97 Things Every Programmer Should Know now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.