The primary goal of any tester is to detect as many bugs as possible irrespective of the techniques (s)he uses. Once a bug has been
found, a tester is required to submit a bug report. Hence, a bug report should be well documented. Make it easy and clear to let the developer know the exact failure of the software. You also let the developer understand and experience the bug for an expected fix.
In order to achieve this, the tester should verify the issue first. Determine what kind of failure it is – if it is a functionality error, validation error, GUI issue, null pointer exceptions, terminal errors etc. Then, replicate the issue to know the exact scenarios and how often the bug occurs. Be sure that you’re confident enough when reporting; this is to keep the accuracy of your report and show the reproducibility of the bug. It would also be better to investigate other details; if the detected bug is the result of other processes of the software or might be a future cause to encounter new bug from other functionality of the software.
The following are the basic content of a bug report:
Description of the bug – State the exact problem briefly. It also identifies when the issue has been encountered. For example, a terminal error occurs when saving a new record.
Replicate the bug – Avoid using paragraphs. Instead, make each step simple and exact to reproduce the bug. For example, [1] Click “Add” button. [2] Enter contact information on the text fields. [3] Select “Save” button.
Provide examples – If necessary, cite examples if a certain test data or inputs are required to replicate the bug. For example, entering these characters “&ao*!” on the phone number text field.
Include screenshots or better create screencasts – Screenshots are helpful to prove that a bug has been encountered and for a developer to see the actual issue. You can also take help of tools like Camtasia to create quick screencasts.
Cite references based on the specifications – If the encountered bug is a functional issue, mention the exact requirements found on the specification document.
Identify the severity and priority – Determine the severity of the bug: For example, if it is a showstopper bug wherein you can’t proceed to testing, then assign it as “Urgent” and “High” priority. Being able to understand the severity of bug shows that you relate the software to what customer needs and shows you understand the nature of the bug you are reporting.
State the expected result – Specify the correct output logically and based on the requirements provided, and if appropriate, explain why.
Once the details above have been accomplished, it would be easier for both testers and developers to do their tasks. It would prevent developers from saying that the bug reported has incomplete details or cannot be replicated; in fact, it will be easier for them to fix the issues. As for testers, they’ll be able to track the bug to fixation and will serve a future reference.