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
|
Attribute |
Description |
Justification |
| Defect identifier | A unique defect identifier, as a rule, is a string containing alphanumeric characters. | It allows you to track the defect while changing its states, and logically relate it with the entire defect fix process. |
| Defect state (status) | One of the admissible states. In the case under consideration such a state is referred to as "new". | Set the defect status as "new" once a defect has been detected. |
| Person who detects a defect | The name of the person who discovers a defect. | Provides an opportunity to ask questions about the defect. |
| Date a defect is detected | At least day / month / year; this field can also indicate the time in hours and minutes. | Allows you to track the history of a defect. Time in hours and minutes can be useful for debugging purposes, if you need to restore the sequence of events that have been tested. |
| Defect detected in the design process | The unique identifier of the software build being tested. | This indicator allows developers to identify the source of the problem and enables the developer or tester to reproduce the problem. |
| Identifier | A unique identifier for the test, during which the problem occurs. If this problem is detected during specialized testing, this field can be marked as NA (not applicable – not applicable). | Provides the developer and the tester with information about which the test should be run in order to reproduce the problem. A test that detects a problem should become part of a regression test designed to ensure that next software releases do not need to be subjected to regression testing. |
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
