In the defect tracking database each defect is assigned a unique identifier, the so-called defect identifier. The defect identifier is a key that supports queries entering the database in such a way that it is possible to obtain information about status of a defect that can be considered as an indicator of the progress in the work to eliminate it. The defect tracking database should store information about who discovered the defect, when it was discovered, the severity level of the defect, and a detailed description of the problems that it caused. If a defect was detected during system tests, information regarding the test that detected this defect should be recorded. For a well-documented test case, it is enough to remember only the test ID. If the test is not properly documented or if a defect was detected during ad hoc testing, it is necessary to record information about the configuration of testing tools and about the special actions performed to detect this defect.
Top 10 software testing companies are among the best qa service providers so do not miss you chance to become their client and your success is guaranteed.
The defect data included in the defect tracking database should be examined by the defect analysis group (or the change control group) in order to determine the severity of the defect. Is it really a defect? Is the defect assigned the right severity? Should it be fixed in the current release of the software product? Information that must be entered in the defect tracking database based on the results of the defect analysis team. As a result of the analysis, the defect is transferred to one of the following three states:
- Fixed – the defect moves to this state if the analysis group decides that the defect must be corrected in the current release.
- Deferred – the defect moves to this state if the analysis team decides to postpone the process of eliminating this defect to subsequent releases of the software product.
- Ignored (trashed) – the defect moves to this state if the analysis team decided that the defect was entered by mistake.
Depending on the final defect status, various data are entered into the defect tracking database. For instance, if the defect is going to enter the “fixed” state, you must write the name of the person responsible for repairing the defect. If information regarding the defect is being prepared to be sent to customers, it is required to attach an explanatory note to the release.
Add Comment