Guest Blog: How to Report Defects Effectively

Technical writers are specialists who can explain technically sophisticated things in simple terms, understandable for a specific audience. They know how to write and at the same time understand the engineering and technologies. Technical writers often face software errors which were missed by the testers for some reason. That’s why the ability to create a defect correctly is an indicator of the professional training of a technical writer.

Every time a new defect is discovered, a report on this defect must be written. If information about the defect is not received sufficiently quickly, it may be difficult to reproduce the circumstances that led to the problem. This is all the more true if specialized types of testing are used. If a documented test case is run, then its outcome can be designated as unsuccessful, and the differences between the actual test results and the expected ones can be registered as part of the test run. Once a specialized type of testing detects a problem or once the test run is completed, a defect message should be generated.

There are different defect report templates that allow the project participants to get a clear idea of how to report a defect. Such template can be presented in a printed form that is manually filled in by the tester, or in a Web data entry form or as part of a defect tracking system database. Such a defect report template is a means of collecting test data.

The success of testing activities depends to a large extent on the skills, experience and knowledge of people who are assigned to make a meaningful defect message. In many cases, the time spent by testers to examine defect reports that were compiled by their organizations during the development of similar projects is of great benefit.

Ideally, there is a set of "golden examples" that allows testers who do not have enough experience to gain an understanding of what a high-quality defect report is and what factors affect the effectiveness of such a message.

Generally speaking, a defect report is considered to be poorly compiled or ineffective if:

• It is made by mistake – the defect described in the message does not exist.
• The problem that has arisen in the description is unclear or ambiguous – the problem may exist, but at the same time it is described so badly that there is no clear idea about the behavior of the system.
• It does not contain the information that the developer needs to playback the problem – the symptoms of the problem are described, but there is no explanation for the actions that caused the problem.

Correctly compiled defect report has completely different characteristics:

• It describes the actual defect present in the software product.
• It clearly describes the symptoms of the problem based on the system’s behavior deviations from the norm.
• It contains a procedure for step-by-step playback of the problem.

From the very moment the defect is encountered, it is necessary to collect a large amount of information about it in order to have less trouble eliminating it.

The table below shows the information on a newly discovered defect that is to be documented in a defect tracking system. This table contains a list of parameters with a brief description of each and the reasons for its registration. If database management tools are used to track defects, the parameters presented in the first column correspond to the database fields.

Table. Data on the defect assigned a status NEW

Testing outsourcing companies are able to carefully, competently and cost-effectively examine software apps under development so it is always reasonable to turn to them for help.

Don’t want to miss the next post? Subscribe to our Blog RSS!

Happy Technical Writing!
ClickHelp Team