How to make your bug report most useless for your team mates

The idea of writing a blog post like this was in my mind for quite a while already, but as too often, I was just procrastinating. Today I have been busy retesting (and closing) a lot of items from our defect tracking system (DTS) and started writing down the following items, as I stumbled upon them (and as they came to my mind as I remembered them from previous projects).

Of course I´m exaggerating a bit on some of the listed items, but all of them are real examples of what I´ve experienced in the past. 😉

So here it is, my (not-yet-complete) list of things to do, to make your bug report most useless for your team mates (none ordered):

• A headline as only description is sufficient; remember: it has to be as short as possible!
• Don´t tell about the expected outcome, just write “feature XY is broken”
• Don´t attach screenshots, or even screen videos
• If you attach screenshots, don´t highlight the area where the problem appears with markers, squares/ circles, arrows, text or other useful things that might be helpful to identify the affected area
• Don´t list the steps that need to be executed to reproduce the bug
• A screenshot of the affected code, taken in Debug Mode of your IDE is sufficient; also non-technical people will be able to grab all necessary information to reproduce/ retest the bug
• Give as less information about the version & environment settings & configurations you tested in; and don´t tell about version/ build number of the application under test.
• If you attach a screenshot, try to make it in the highest resolution possible; people with smaller screen/ resolution don´t need to get a quick overview
• On screenshots, cut an area as small as possible that is showing the buggy area; all surrounding additional information is just distracting and not helpful for solving a bug
• Just describe a behavior, don´t give additional information, like “this is the expected behavior, but it behaves different like that”, or “this is the actual behavior, but I would expect it to be like that, because of …”
• Don´t give any further information then just copying an extract of a (as cryptic as possible) application log file. Don´t limit this to excerpt of the log file; post an as big as possible log.
• Don´t attach screenshots as PNGs, use TIF, GIF or BMP instead, or even better, paste your screenshot into a Word/ Excel/ PowerPoint/ PDF file and attach this to the bug report
• Don´t give information about the test data you´ve used when finding that bug. This additional data would just be too confusing, it is absolutely clear, that you had that buggy behavior because you worked with test data that´s representing an edge case.
• Don´t use line breaks, punctuation marks, paragraphs or upper- and lower case to make your text more readable.
• Don´t try to avoid misunderstandings and ambiguous terms; everybody will know about your context when writing the bug report, because crystal balls are standard equipment nowadays.
• Don´t update the status of the bug report in the bug tracker so that it will reflect reality; especially don´t set (successfully) retested resolved items to “Closed”, hundreds of items in state “Resolved” items don´t pollute the bug tracker, they are rather a proof of how many bugs have been fixed by the hard-working programmers.
• If you have already discussed the bug upfront with someone else, just note done „As discussed with Fred“; no further info is needed, even if no one else has been present when the two of you talked about this issue.

Please let me know if you have made experiences that are missing in the list!