Writing a good bug report is an art.
Bug reporting is a skill that depicts
what exactly an issue is and if the bug report sounds effective than there are
higher chances to get it fixed. Logging a bug is a part of task for testers but a good tester
should write an effective bug. There is a huge difference between simply
logging a bug and reporting an effective bug as effective bug reporting
increase the chances of it getting fixed. So, let’s share some important
guidelines to write a good bug report so that the developer can understand,
replicate and fix the issue:
1) Finding and reporting the root cause of a bug is very important as that would give developers a straight forward way to fix the bugs.
2) The title of the bug should be clear enough so that developer should be able to understand the bug by reading the headline itself. Headline should be small, to the point and self explanatory.
3) Focus on its reproducibility rate, be precise, articulate well and report it in a way that no further questions for additional information from the developers are raised once the bug is logged. This would not only make communication between testers and developers strong but also help in building healthy relationship between them.
4) Once you find a bug in one module then always test other similar modules as well. Try to reproduce the bug in related modules because there are chances that the same bug may occur in other related modules also.
5) Most of us have the tendency of buffering the bugs in the day and logging them at the end. This is not a good approach to follow as it would result in wastage of time and more effort is needed to reproduce it again and there may be a chance that you might overlook some important steps. There may be cases that issue may not reproduce at the end of the day due to some reason; which can even be a new build deployment. So, it is always a good practice to log bugs as soon as they are discovered.
1) Finding and reporting the root cause of a bug is very important as that would give developers a straight forward way to fix the bugs.
2) The title of the bug should be clear enough so that developer should be able to understand the bug by reading the headline itself. Headline should be small, to the point and self explanatory.
3) Focus on its reproducibility rate, be precise, articulate well and report it in a way that no further questions for additional information from the developers are raised once the bug is logged. This would not only make communication between testers and developers strong but also help in building healthy relationship between them.
4) Once you find a bug in one module then always test other similar modules as well. Try to reproduce the bug in related modules because there are chances that the same bug may occur in other related modules also.
5) Most of us have the tendency of buffering the bugs in the day and logging them at the end. This is not a good approach to follow as it would result in wastage of time and more effort is needed to reproduce it again and there may be a chance that you might overlook some important steps. There may be cases that issue may not reproduce at the end of the day due to some reason; which can even be a new build deployment. So, it is always a good practice to log bugs as soon as they are discovered.
6) Bug should be filed with all possible
required details so that when a developer reads it, he should not resend the
bug asking for some more information regarding the bug.
7) Screenshots where ever possible should be attached, if it is not
possible attach a screenshot Video files should be attached.
8) Reference to the document, if any, which has been referred for the expected result should be provided.
8) Reference to the document, if any, which has been referred for the expected result should be provided.
9) If a bug is related to other bugs, then
please include that information in the bug reports.
10) Everything should be explained in
such a way so that developer shouldn’t get confused.
11) All the
required information like the URL, user name etc should be mentioned in the
description.
12) Proper
affect version should be mentioned as this helps to diagnose when the issue was
introduced.
13) The Language used should be to the point and any story writing practice should not be followed.
13) The Language used should be to the point and any story writing practice should not be followed.
For any further query log on to: http://www.qainfotech.com/case_studies.html
