Hide Notes 

Slide 1: How can we do a good bug reporting It is a quite common comment received from a developer, that the Bug report is not clear. The steps to reproduce are Vague, captured screenshot is not effective, and many more are usual complaints which tester can hear in his career. Hence, reporting a bug efficiently and effectively is as important as identifying bugs. Reporting a good bug is not hard, but many times we do it in a hurry and without putting our full attention into it and hence when a bug is not reported properly it may end up in Wasting our time to report bug incorrectly and additional time to correct and rewrite it Wasting the time of other people who review it and trying to make sense of what we wrote Reduce our testing professionalism, by writing a bug that is correct but incomprehensive The following components could be considered for a good bug reporting 1. Short and precise title Each bug should have its individual title. The title gives us the opportunity to quickly understand and remember what the bug is all about. The title cannot be generic (e.g. Error on Application), or too long. It should be one sentence, providing the highlights of the issue and the way to understand how a user could run into it. 2. Concise but complete description The description of the bug is where the tester can express his artistic sense and write what he thinks will help developers/business users to understand and handle the bug. Items like Steps to reproduce, consequences of bug, and suggested behavior can be included in the bug report 3. Good attachments Attachments always help the testers in forecasting the issues to developers. This is especially true when we need to show GUI malfunctions, error messages, and/or log files that compliment the description of our bug. One thing to take into account is to provide only the relevant information in attachment. This means that if we have a long log file we can attach only what we know is relevant and not all of it, and capturing the error screen part instead of pasting the entire screen window, etc. Use also zip files and compressed formats as attachments in order to save space. 4. Complete definition of the categorizing fields Information like Module, Infrastructure, Browser, etc. related to the functionality, in which bugs was found can be described. Visit IVESIA’S WEBSITE Follow us at LINKEDIN and TWITTER
Slide 2: ‘ ‘5. Correct Severity & Priority Another big Tester Sin is to over prioritize bugs. Obviously tester is happy when he found a bug and want it fixed, but giving it the wrong severity will only make the person in charge of the bug angry and it will lower the chances of having this bug fixed. Creating S1 – Critical A defect that causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround. We can note down the important bugs that were reported from customers and we assured them will be fixed. S2 – High The defect causes a part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users. High visibility GUI issues can come under this. S3 – Medium The defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users. S4 – Low The defect causes no dysfunctions to the system and may even be unnoticed by most users. The bug has an easy workaround or may not even require a workaround at all. S5 – Enhancement Request or Suggestion The items which the tester thinks, that it could be enhanced 6. Follow-up and comment. We should continue following up on our bugs, and providing comments when necessary. This is especially true when a developer or other stakeholder does not understand the bug, and either rejects it or delays it. Visit IVESIA’S WEBSITE Follow us at LINKEDIN and TWITTER