怎样写测试缺陷报告（英文）

Defect reports are probably primary work product for most of the software testers. Good bug report, which is informative and understandable earns you a good reputation. Weak report generate extra work for everyone. Most of the time, a weak bug report is returned with comments saying not clear, need more information etc. That makes you work again on the same defect and thus reduces efficiency of testers and developers both. Defect reports are not only used by programmers, but also by managers, executives,documentation team and support executives for various reasons.......

Defect Report

Defect reports are probably primary work product for most of the software testers. Good bug report, which is informative and understandable earns you a good reputation. Weak report generate extra work for everyone. Most of the time, a weak bug report is returned with comments saying not clear, need more information etc. That makes you work again on the same defect and thus reduces efficiency of testers and developers both. Defect reports are not only used by programmers, but also by managers, executives,documentation team and support executives for various reasons.

Purpose of a defect report is multifold in any organization. Defect reports are used to

• Alert software programmers about the defect and gives them sufficient information to find root cause and fix the problem.
• Provide information to technical writers who are writing troubleshooting, known limitation etc.
• Provide starting point for the next release
• Add test cases in the regression suite for next release.

According to Dr. Cem Kaner, A good defect reports should be simple, understandable, reproducible, legible and non-judgmental.

Defect Report Template
A good defect report might have following sections.

• Headline
  One line description of the defect. Remember, A good headline will always be clear, related to the defect and give some hints on how critical defect could be.
  
• Product
  In most cases defect tracking system is used for more than one product. So specifying appropriate product and version is very important.
  
• Component
  Products are normally very complex, and can be divided into components. A defect report containing proper information about component can help managers in assigning it to appropriate person.
  
• Defect Type
  Defect type could be, functionality, specification, regression, UI etc. This classification can be used to analyze how defects are distributed in the system.
  
• Priority
  Priority is the impact of defect on business. This field gives an indication of the impact of this defect on business. In some organizations, testers do not specify priority, It is defined my manager or triage team members. 
  
• Severity
  Severity is the impact of the defect on the product. For example if you hit five keys together and your product crashes, it is a very severe defect. But its  priority is probably low because normally people might not hit five keys together. Now consider that the  company logo is not proper on the splash screen. From severity point of view it is not severe as it is not crashing application or blocking user from using the application. However, it is hig priority as it is affecting organization's image.
  
• Environment
  Proper information about your test execution environment should be present. For example, information about platform, databases, run times everything should be included in your defect report. This information helps development team in reproducing the defects.
  
• Steps
  All the steps should be specified clearly. You should not assume that programmer will understand this. Programmer might be looking at your defect report when are not  around to explain. Your steps should be clear enough for a novice user to follow and reproduce or verify the defect .
  
• Attachments
  Whatever additional information is needed for the defect, should also be attached. This additional information could be logs generated by system, application etc. It could be screen shots or any other thing that might help developers in reproducing the defects.
  
• Comments
  If you have any additional comments on the defect, you should specify it clearly. For example if you observe/think that defect is related to some other defects filed in the same component with little variation. You should specify that.