February 2010
Beginner
255 pages
6h 10m
English
Content preview from 97 Things Every Programmer Should Know
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
Start your free trial
Chapter 38. How to Use a Bug Tracker
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 of a bug is a ...