Do you find yourself in a situation where developers ask you each and every time to reproduce the bug which was reported?? Are they not understanding the defect?
Being in a quality testing department, a quality tester should be good in communication and writing skills. Development team should never come back to a tester asking him to reproduce the bug (Even once). If this is achieved by you in every defect then you are a 100 percent good defect reporter.
Being in a quality testing department, a quality tester should be good in communication and writing skills. Development team should never come back to a tester asking him to reproduce the bug (Even once). If this is achieved by you in every defect then you are a 100 percent good defect reporter.
A good bug reporter should always keep these things in mind while logging defect.
1) Defect Summary: Defect summary should be kept short and sweet. Just by looking at the summary the developer should understand what the bug is all about. I frequently see testers being very vague in providing proper defect summary. If the defect cannot be explained in Defect summary then use following sentence : "Application crashes if following sequence is performed in so and so screen". and explain the defect by providing proper steps in description.
2) Severity: Severity plays an important role while logging the defect. Developers would plan fixing of the defects depending on the severity. As a tester we need to always be a good judge in marking the severity. Many companies have following severity in bug tracker depending on the following criteria
- Critical: If the system crashes or certain functionality is not working or there is loss in data.
- Critical: If the system crashes or certain functionality is not working or there is loss in data.
- High: If feature doesn't work as per the business requirements or there is no possible way to proceed to next step of testing.
- Medium:Highly visible usability and UI issues and if there is a possible workaround.
- Low: Cosmetic flaws
So make sure the defect is logged with correct severity.
3) Build information: Make sure build number or release number is entered properly to further reduce the confusion.
- Medium:Highly visible usability and UI issues and if there is a possible workaround.
- Low: Cosmetic flaws
So make sure the defect is logged with correct severity.
3) Build information: Make sure build number or release number is entered properly to further reduce the confusion.
4) Device Information / OS information : Make sure proper device model and OS is mentioned. If the same defect exists in other devices or OS then mention those devices too.
5) Assign defect: It is better to know who is handling what module as project starts so that assigning the defect becomes easier. If you don't know who is handling the module assign the defect to project owner so that the PO can assign the defect to concern person.
6) Steps: Make sure the steps are mentioned properly, right from the start till end. Each and every step is very important to be written, be it a simple tap or some unusual sequence. If there are any screenshots attached, make sure you mention the screenshot name in steps itself. Have expected and actually result properly mentioned. If any additional info is required, mention those points too.
7) Screenshot: Always make a habit of attaching a screenshot to the defect as it gives more clarity about the defect. Using an annotation, mark the area in the screenshot where glitch or UI issue is found. If there are multiple screenshots then make sure that proper name is given to each screenshot. Its better to have a build number along with the screenshot so that if there are similar bugs found in next build then the screenshot could be named with the present build number to reduce confusion.
Let me know if I have missed anything. Cheers.
Let me know if I have missed anything. Cheers.