Most of the times testers get irritated when developers reject there defects or when they reassign them to the testers for more information. Why do this happen? What is wrong with the posted defects? These are the questions which usually arises in a testers mind. Especially with the newcomers. Moreover, a lot of time is wasted for both testers and developers if the defects are not communicated properly.
The best solution to avoid this is by reporting the defect with all the necessary details, so that the developer can reproduce/understand the defect.
There are various benefits when the defects are reported effectively. Some of them are:
1. The communication between the tester and the developer decreases. So, no time is wasted.
2. The defects get fixed quickly.
3. The tester can reproduce the defect as per the steps during retesting of a defect. No confusion for a tester on seeing his own defect after a long time :)
The following are some of the ways to improve the quality of bug reporting:
1. Firstly, try to reproduce the defect. Note every step you perform in the report.
2. Note down your observations.
3. Take some screenshots/movies as applicable and attach them.
4. Provide the system info for any defects noticed due to some system configurations.
5. Take the image of the OS if possible.
6. Rename your screenshots/movies/attachments accordingly.
7. Give the descriptions of the attachments in the defects.
8. Last but not least, make sure that your defect is reviewed by your peer before you submit. This will help to post your defects in a very efficient way :)
1 comment:
My experience taught me the following guidelines for creating/managing defects:
-> Make sure that IT IS a defect - This means cross verify all the documentation, check with your peers and manager and get it confirmed as a defect, if possible, from DEV team. Then reproduce it few times and make sure it is consistently reproduced before posting the defect.
-> Understand how to set "Severity" to a defect. Come to common agreed-upon consensus after discussions with QA team/manager about the criteria for each severity - For example, what is the criteria for a defect to be of Severity 1?
-> Be as crisp and simple/straight forward as possible. Do not use complex/ ambiguous words/phrases when authoring the defect.
-> Mention in detail, the environment details, builds, steps to reproduce and attach necessary proof for the defect (Logs, screen-shot).
-> There is a big discussion on whether a defect can be marked as a frequent/in-frequent. Some people, even at high levels say that there is no concept of an "In-frequent" defect. This is infact true to a certain extent, because a defect unveils only when a specific condition occurs. If you are not able to reproduce the defect frequently, it means that the condition is not being met. So, the best way is to attempt to find the root cause by investigating on the defect and then mark it as a frequent one, rather than blindly raising the defect as in-frequent.
-> When closing the issue or when re-opening it, mention all information required - Build tested, New logs captured, steps, etc.
-> Last but not the least, it is a best practice to brainstorm with-in the QA and DEV teams and come-up with a document with the agreed-upon set of guidelines one must follow to raise, close, or change the status of an issue. Then on, all the QA team must strictly follow that document. This will avoid many hassles and keep all relations intact :-)
Post a Comment