I reckon that question is something we ought to hardwire into our systems. After all, the main reason why we log bugs is to have them fixed, and helpful bug reports just make it a bit easier for us and our devs to close the bugs. How so?
Helpful bug reports allow the devs and testers to easily replicate the bug. In order to fix a problem, you’d need to be able to see it first. This also goes for testers who need to verify a bug fix (especially when reported by someone else) i.e., we ought to know what was wrong to begin with and what has been changed in order to close the item. If you happen to be a forgetful tester like me, logging enough details on how to replicate the bug and other background info on the bug helps refresh the memory.
Unavoidably, there are cases wherein the bug is very difficult to replicate or it happens intermittently. For such cases, indicate that info in the bug report so that the dev or the tester who’s trying to replicate it knows that the bug would be a challenge and so that the bug won’t immediately be dismissed. Provide as much background info as you can recall when you first encountered the problem, and provide additional details whenever you encounter it again.
Helpful bug reports help isolate the problem. The problem’s easier to address if you know which particular cases trigger it. Say, it’s a problem that occurs across all screens, then it could be a framework bug or a browser-related problem. If it’s a problem that only occurs for particular data or in particular environments, indicate it in the bug report.
Helpful bug reports are written with some consideration on who’s going to read them. It’s easier when you report a problem to your dev since both of you are working on the same function. But sometimes, you have to report a bug to a framework dev who may not have as much background on the domain as you do. Or sometimes you have to report a bug that will be handled by another tester. Or sometimes you have to report a bug that will need to be reviewed and approved by the HK SA. For such cases, you need to provide enough background information for the bug report to be better understood.
Helpful bug reports provide information on the expected results. Say, a tester found a UI bug wherein a particular text that’s supposed to be bold is italicized. The report shouldn’t be something like the ‘text “blah blah” must not be italicized.’ The dev might just remove the italics and not set it to bold. If you know the expected behavior, then provide the information. If you know of a forum topic discussing the bug, then post a link to it and post a summary of the resolution once it’s already available.
Helpful bug reports are concise, without leaving out the details that could be useful. Provide the details without being too wordy about it. Too much text tends to make the eyes glaze over. And with that note plus some links below, I end this post.
A friend had shared with me a paper on bug isolation. It’s a 2004 paper by Danny Faught entitled How to Make Your Bugs Lonely: Tips on Bug Isolation. It starts off with the quotation: “A problem well-stated is half-solved.” The paper then got me thinking on whether we cover or emphasize this strongly enough during tester training in our company. Sure, our testers indicate the expected behavior versus the actual behavior in their bug reports, and sometimes they provide the steps to replicate the problem. But giving the steps does not necessarily equate to giving the conditions that trigger the bug report.
In bug isolation, one attempts to really zero in on the bug by reducing the factors that obscure the problem. For instance, you streamline the steps to get to the bug, or you narrow down the data needed to trigger the bug. Basically, you refrain from posting shoddy bug descriptions like “It doesn’t work”, and instead you try to find out the specific conditions that trigger the bug. You might think that bug isolation only benefits the developers since they’ve less effort to render in trying to replicate the bug. But I think, this will also help the tester in thoroughly verifying bug fixes. How else would one know if a problem is solved if he doesn’t know the problem to begin with. Verifying the absence of the previously detected symptoms is not always a sure-fire guarantee.