Defect Report is probably the main deliverable for most software tester (test systems). A good report faults, represents a very important and understandable information. In contrast, a weak Defect Report, it generates extra work for others. Most times, a report of weak defects is returned with comments like: not reproducible, it requires more information it is not understandable, poorly tested, and so on.

This leads to work as a result again on the same defect, and therefore reduces the efficiency of developers and testers. Defect Report is not only used by programmers, but also for managers, executives, project team and support staff, ie that such documentation is "exploited" for different user roles within an organization to different purposes.

The purpose of a report defects in any organization is changed, because it is used for:

• Alerting systems programmers about the defect, giving them enough information to find the root cause and thus solve the problem originates.

• Provide technical information to those responsible for drafting the "troubleshooting" or reports of limitations will then for example to support users.

• Provide starting points for the next version of the system

• Incorporate test cases for regression testing in the next release

A good Defect Report should be simple, understandable, reproducible, legible, and without prejudice.

The basic structure of the template should consist of the following sections:

• Title
• Product
• Component
• Type of Defects
• Priority
• Severity
• Environment
• Sequence of steps
• Attachments
• Comments

1. Title

Brief description of the defect, if possible in one line.

2. Product

In general, the defect-tracking systems manage more than one system (with their corresponding modules), which is why it is important to specify (in case the application fails to do so) to the product or version is concerned.

3. Component

This point is related to the previous point where you specify in more detail about which component should be acting to correct it is, for example, that system module fault has occurred. In this way, this information will assist the manager in the allocation of its correction.

4. Type of Defects

The type of defect could be: aesthetics, navigation, functional, not functional, regression, etc.. In this way, this classification may be helping to further analysis of how they are distributed defects in the system.

5. Priority

This factor is the impact that defects in the business, ie how much impact their effect on the operation of the business. Usually, this factor does not edit or modify the tester but the person who is responsible for development, or functional test, or project.

6. Severity

Is the impact of the defect.

7. Environment

Information related to the environment on which it must be running the test.

8. Sequence of steps

Is the sequence of steps, points and interim results to be followed to the effect that anyone can just reading, to reproduce the fault.

9. Attachments

Can be offered to programmers, eg screenshots (screen capture) files generated by the proven option, logs, etc..

10. Comments

Any information that can supplement the understanding of the programmer fault.