Ideas on Reporting a bug
Author: Yaping Xin
Date: April 2009
Open a bug
The tester must fill in all required fields using the following template:
a. Title: using exacted, simple and clear words to enable the others can pick it in a search result and grasp the main point at the first glance.
Path: make it exacted as far as possible.
b. Under status section
Assigned to: set as “active” before triage.
Priority and Severity:
Issue type:
Issue sub type:
Security Rating:
c. Under Opened/Closed section
Build:
How found:
Language:
d. Under Project section
Some needed content have to be filled in.
e. Repro Steps
This field is very important. Be sure to fill in enough information so that the others can follow your steps without misunderstanding.
The repro steps should contain the following parts:
1) Pre-Conditions (if needed)
2) Repro Steps
3) Expected result
4) Actual result
If necessary, add screen shot files and result logs as attachment.
f. Description
Leave it blank when you open the bug. This is important. The description can’t be edit or removed, we can only add content into description, so please be cautious to fill in description after the bug be triaged.
g. Files/Links section
It is very useful to upload screen shot images, log files, exception report dump file or the other files to help the one who will repro/triage/investigate the bug.
We have to assess all the bugs on a daily manner (sometimes twice a day), and see which ones we are going to bring up to local (and shortly global) investigation teams, where a lot of people participate, and the time is pretty valuable.
When open/update a bug
• Make *triple* sure that you have added fully explanatory repro steps that anybody can pick and repro. Screenshots are extremely valuable, and any other attached files that support the bug should be added.
• Links to other bugs are useful, if the other bug might have some supporting information to explain decisions or the evolution of a previous bug.
• Make sure that you are marking the Regression field to identify if it is a regression from a previous build of this release.
• As always, use your best judgment for priority/severity/blocking.
• If a bug was found due to a failed test, not only add the reference to the test case, but also add all of the steps the test is doing to the bug repro steps (that way no time is lost in finding the repro steps).
• Always break down your bug report:
(a) Do NOT mix issues with different root cause into one bug.
(b) Add exact steps which can always repro the bug, and remove the unnecessary steps.
When you are assigned a bug for investigation
• Bugs set for investigate are not meant to be fixed right away usually (even if possible), as we still have to get them approved before you can check in a fix.
• It would be fantastic if you can explain what customer scenario gets impacted, what is the customer impact, what is the workaround if any.
• If you have an idea of the code that needs to be fixed or how you are going to fix it, please assess the risk of impact to other areas or regressions and put it in the bug.
• Once you are done with the investigation, you can assign it back to triage for a decision.