So you’ve found the bug and know exactly (hopefully) how to reproduce it. Now you’ve got to tell someone, and that someone is likely the developer. So how do you go about documenting and submitting the bug? Here are some helpful tips for the end of the process:

Documentation

It’s great to find bugs, but if you can’t or don’t explain them properly to the person responsible for fixing the bug, at best you’ll confuse/frustrate him while wasting his time, and at worst you could prevent the bug from being fixed at all. There are two key principles in documenting a bug. Specificity and perspicuity (or being clear).

Be Specific

When writing up a bug, be as detailed as possible. Where exactly did you find the issue, how did you get there, what did you do? These are all very important questions. The more information you give, the less time the person correcting the problem has to spend figuring out what you mean. Since we’re working on a website, give URLs, breadcrumb trails, and anything else that could help. Write out step by step how to reproduce the error, starting with the homepage for customers, and the administration home page for the back-end.

Be Clear

Perspicuous means easily understood or comprehended. In the case of bug documentation being clear with your instructions is crucial. No matter how detailed you are, if your documentation is filled with typos, awkward sentence structure, or confusing or ambiguous language, it helps no one. The harder your documentation is to understand, the more time the developer has to spend to figure it out before he can fix it. In many cases, the developer may have to ask you what you meant, wasting even more time. Take the time to get it right the first time so you can be efficient.

Verification

Once you’ve submitted a bug and the developer has (supposedly) corrected the issue, you may be notified and asked to verify that the bug is indeed corrected. If this is the case, please take time to go and make sure you cannot reproduce the bug you reported. Do not take it for granted that the bug is fixed. Also, do not try to reproduce the bug before you are notified it has been fixed. It may be that your bug was determined to be a low priority or a non-issue, which means it may be a long time before it’s looked, if at all.

Following these guidelines for documentation and verification can drastically streamline the process and increase productivity.