Creating a Defect Report

A development project will usually have a central defect database for recording and managing all issues, incidents, defects, or failures that are discovered in the course of testing and use of the product. As previously mentioned, defect reports can relate to any kind of issue in a system or its components, as well as errors, faults, or gaps in the requirements, technical specifications, user manuals, or other documentation. Such reports serve to inform and communicate among all project participants.³¹

Report defects but don’t attempt to analyze them

Creating a new defect report has nothing to do with establishing its cause or finding a solution. This happens later and is handled by the responsible developer who performs appropriate debugging.

A defect report has to describe the observed effect and its context, including any other side effects it has on the user or other parts of the system. A defect report must be precise but brief so that the responsible developer can quickly understand and reproduce the situation with a minimum of effort³² and find a solution as quickly as possible.

Standardized reporting template

To keep these lines of communication running smoothly and to enable statistical report analysis, every report has to be made according to a strictly defined project-wide template.

Alongside a description of the issue itself, a defect report typically contains additional information that identifies the software being tested, the test environment, the tester’s name, some kind of defect classification, and any other information that helps to localize and reproduce the issue.

Case Study: The VSR-II defect reporting template

The VSR-II team decided to use the same basic defect reporting template workflow from the predecessor VSR project, as this proved useful and reliable. Table 6-1 illustrates the basic reporting template:

Table 6-1Defect report template

ISO 29119, Part 3 contains another sample defect reporting template³⁵ [ISO 29119].

Tailoring

How a defect, issue, or incident reporting template actually looks will vary from project to project. The test manager or QA lead for the project has to create a template together with all those concerned. Some of the factors that influence the template are the lifecycle development model in use, the number and size of the team(s) involved, the context and criticality of the system being tested, the number and types of test levels, and the need for and purpose of any statistical evaluation. Smaller projects can do without many of the attributes listed above, and any attributes that are never evaluated should be left out anyway.

Our Tip Using defect management tools

• When setting up or improving the testing process, one of the first things you should concentrate on is designing and implementing a disciplined defect management process. To do this, it is essential to select, install, and configure an appropriate defect management tool. The configuration should give all project participants access rights appropriate to their roles within the team.
• Defect management tools can automatically set reporting attributes (for example, automatic numbering or author identification) or check their validity. Most tools also offer configurable user roles (such as tester, or test manager) and defect management workflows. Once configured, the tool can automatically check that the workflow is adhered to.

Document all information relevant to reproducibility and fault correction

It is important to ensure that the recorded information enables fast reproduction of the failure and the localization of potential causative faults, as well as process status indicators and statistical metrics.