Writing defect reports

Most projects use some kind of issue tracking system. It might be something custom (e.g. a bug-tracker based on sharepoint), some free tool like Bugzilla, or a fully loaded commercial tool – e.g. JIRA. But no matter what tool you choose, the template used for bug reporting is pretty much the same. Of course it is very important to accompany your issue with a valid priority, severity, build # or version, assignee and such, but I would like to emphasize the following three fields: Summary, Description, Attachments. The information provided in these fields will directly impact the perception and understanding of the defect and its future. Providing decent info to these fields requires from tester some efforts and a certain level of knowledge of AUT.
So, let’s get to the subject.

1. Summary
The defect’s curriculum vitae, aka Summary – this is the first thing anyone will see in you defect report, thus very important. Lots of stuff depends on how good the summary is defined. It is a success if the developer got by no less than 80% the essence of the defect after he’s read the summary.
I advise you keep in mind the following things while writing your next defect summary:

1) denote the platform (e.g., test, branch, prod, etc.) if there is more than one

2) specify the component (e.g., аdmin, reports, upload, navigation, etc.) if the following part of summary may fit several components and can be interpreted ambiguously

3) point to browser, OS or any other specific part (e.g., fails in FF 3.6 on Mac) if the defect is reproduced under custom configuration
4) mention the reproduction frequency (e.g., occasionally or 4 of 10 times) if you cannot reproduce it each time
5) use the definitions and names equal to what’s used in your AUT (e.g., not “photos”, but “images” or not “scroll bar”, but “slider”). Do this even if you know that it’s not the correct name for the subject

2. Description
Steps presentment or the Description – is the most important part of the whole report. The future of the defect depends on these simple step essays. On one hand, if the ‘Steps to reproduce’ section is too short and laconic, there is a big possibility that the bug will be returned to tester with resolution ‘incomplete’, ‘rejected’ or something similar which is a waste of time. On the other hand, too many details will “frighten” the developer and he’ll leave that particular issue for later – when he has time for reading novels like that.

By saying that I can conclude that it is vital to choose an optimum-scale Description detail level. My personal choice is a rather detailed defect descriptions (a bit more detailed than what you’ve probably consider medium detail level) with grouping easy unambiguous steps into one
Remember, a good problem description makes a half of its solution.

3. Attachment
I consider it a testing decency to attach some sort of visual ‘proof’ to defects (of course it’s not all defects that require a visual aid, but most do). The most widespread kind of such ‘proof’ is a screenshot (my ‘weapons of choice’ are described here). Actually, having so many screen-content capture tools makes it no problem to attach a video as well. Some developers will really appreciate video attachments, because it can save their time spent on understanding the root cause.

Speaking about defects I must say that a good tester not only finds defects but also makes sure that the found defect gets fixed. And remember, if your bug has returned to you with resolution any other than ‘Resolved: Fixed’ – it’s your fault.

P.S. If you are not sure about how good you are coping with the three mentioned points – do not hesitate and ask those who works with your ‘essays’ on everyday basis – your dev team.

Also available in russian.