Anybody who has made software must have faced a bad (not understandable) bug report. Something like “It doesn’t work at my end”, sometimes reports make no sense, or reports do not give enough information. This leads to a lot of to and fro emails/ calls/ discussion’s which leads to wastage of work hours which could be avoided with an effective bug description.
So what makes an effective bug description, I will try to explain that in this blog.
- Make a precise bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
- If the first aim does not succeed then let the programmer see the failure with their own eyes. If you can’t be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
- By all means, try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
- Be ready to provide extra information if the programmer needs it. If they didn’t need it, they wouldn’t be asking for it. They aren’t being deliberately awkward.
- Write clearly. Say what you mean, and make sure it can’t be misinterpreted.
- Enter clear steps to replicate the issue and enter as much information as possible. Give screen shots of the issues that you see.
A good bug report should have the below details:
Description: Write a small description of what the issue is, a small description which would explain the bug completely.
Summary: Brief Summary of the issue.
Steps to Replicate:
Step1: Do this.
Step2: Do that.
Step3: See this and that.
Actual result: Write something that you seeing on your screen.
Expected result: Write a brief description of what should have been the expected result.
Additional Info: Give some more information if possible which could be beneficial to the developer to replicate this issue.