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.