How to write a good bug?（转贴）

• While reading a bug assigned to a developer, he/she should have all the information related to the bug. (Ex: Environment, IP, exact repro steps, what is the actual result, what is the expected result, any other notes you need to include etc. Other very useful information to include in the bug is any error events in the event viewer logs,SQLquery you used against the db (to verify information logged in db), which SQL server & db you are using, a screenshot if it is a UI bug, etc if applicable etc.

Howto Steps

Notes: Before filing a bug, make sure of the following :

• Make sure it is a bug & not expected functionality. Verify against spec. If information is missing from the spec, check with PM & file a spec bug to update the spec.
• Check for duplicates. If a bug already exists for the issue at hand, read the bug. If you think you have gathered more information than what is included in the bug or have exact repro steps, please include them in the existing bug as well.
• Check on HF box if bug is existing on live site as well.
• Does it repro on other place (if applicable).
• If your bug includes more than one issue, try to search if the other issues are already in raid. If yes, link the bugs.
• If the bug fix or details for the same are being discussed in email, make sure to include those details in the bug as well.
• When closing a bug, please include details on the repro steps you followed & all the areas you verified (db, event logs, different place, etc), especially if you are verifying a bug that is not opened by you.
• When regressing a bug, also include other existing functionality verified in addition to the bug fix in the bug details, to make sure all the areas affected by the fix are working correctly.

Anatomy of a bug:

• Title:Titles should be Clear, Concise, and describe the problem accurately. If you are writing one bug for 2 related issues, please file 2 different bugs & link them. A good title of a bug should include three sides , just “Who , What , Where”.
• Status:
  1. Status:By default opening a bug sets it state to active. If you resolve a bug, make sure you change the status to resolved.
  2. Assigned To:Assign bug to the right person. If you are not sure, check with feature PM or your manager.
  3. Issue Type:Select the correct Issue type from the drop down.
  4. Severity & Priority:Complete these fields correctly with the new definitions.
• Opened:
  1. Open name:Who opened this bug?
  2. Date:When is this bug be opened?
  3. How Found:bycheck requirement or by test etc.
• Project:
  1. Project name:Which the project name did you find the bug in?
  2. Module name:Which the module name did you find the bug in?
  3. Open Version: Which environment did you open the bug in ?
  4. Fix Version: Which envt do you want this bug fixed in?
  5. Milestone:When do you want the bug fixed by?
• Bug Descrīption:
  1. Descrīption: A more detailed explanation of the problem.
  2. Steps to Repro: Good repro steps require less investigation by both dev and test.             Good repro steps always begin with a link to the site where you found the problem. Good repro steps can be followed by someone unfamiliar with your area.
  3. Expected Result: The descrīption should also contain the result you witnessed and the result you expected (and any clarification needed as to the difference).
  4. Actual Result: A descrīption of what happened after the above steps were followed.
  5. Attachments: A screen shot can also be attached and can add a great deal of clarity. A picture is worth 1000 words... (save as jpg or gif, to avoid 2 MB bitmap files, Power Point is a good tool to show successive steps to repro the bug ) .
  6. Other place: This kind of bug if it can be find in any other place or not. Does it happen in the other condition? Does it happen in the other language?
  7. Browser: Which browser is this bug be found in? (use in WEB test)
  8. Automation/Tools: If it is found by auto tools or not.
  9. Events/Logs
  10. DB Server/DB/SQL query