Handling a Defect - Procedure

Handling a Defect - Procedure

When a defect is taken into the administration, it enters the defects procedure.

Progress of the solving of defects is discussed in a periodic defects consultation. During the preparation and specifying of tests, this consultation is usually held once or twice a week. During test execution, it often increases to once a day. Participants in the consultation are representatives of the parties who submit and/or deal with the defects. From within the testing, this is the test manager, defects administrator or the intermediary. Sometimes a tester is invited to explain a defect. Other parties may be the user organisation, functional management, system development and system management. The defects consultation is also sometimes combined with the handling of the change proposals in, for example, a Change Control Board.

In order of priority, the participants discuss each new defect and decide whether it should be solved, and if so, by whom. In this consultation, the correctness, cause, priority and severity of the defects, as well as the costs of solving them, are discussed. A familiar humorous reaction of developers in this connection is "It's a feature, not a bug". The representative of the testing also has the job of ensuring that the importance of a defect (severity and priority) becomes sufficiently clear to all the parties. The consultation may also request the submitter of the defect to provide additional information or carry out further investigation. The participants in the consultation determine, after carrying out the necessary discussions, the definitive values for cause, priority and severity of a defect.

If the defects consultation agrees that it is a valid defect and the costs of solving it are acceptable, the defect is assigned to a defect solver. If the consultation agrees that it is not a valid defect or that the costs, lead-time or regression risks of solving it are too high, it is rejected. A valid defect that is nevertheless rejected is also known as a 'known error'. In the event of rejection, it may be decided to submit the defect via another channel as a formal change proposal or to devise a procedural solution. Examples of procedural solutions are notes in the help text, instructions to the helpdesk assistants or amendment to the AO procedures. If the consultation does not agree, then the defect is escalated to the decision forum. Representatives of the parties with decisionmaking powers sit in this forum, such as the client and project manager, who decide on whether or not (and when) the defect is to be solved. The decision forum is not necessarily an independent consultation, but is often the project management meeting or the project board meeting.

The diagram below shows the relationship between the defects consultation and decision forum:

The defect solver investigates the defect and solves it. Or it may emerge that the defect has been incorrectly identified as such (a testing mistake) or should be handled by another defect solver. In the latter cases, the defect goes back for discussion. If it is solved, it can be transferred at any time to the test environment to be (re)tested. The tester, preferably the original submitter, carries out the test and checks whether the defect is solved. If so, the defect is closed. If it appears that the defect is not (adequately) solved, then its status is reset and it again undergoes the defects procedure. The retesting of the defect is an essential step in order to be able to close it. It is unacceptable for the defect solver to solve the defect, test it himself and then close it. Checking whether the defect is solved is the task of the submitter (or his replacement).

The figure below shows the life cycle of a defect according to the above procedure, in which the texts in the rectangles show the status of the defect. The diamonds refer to the actors. The dotted line from "Postponed" to "Allocated" means that the defect is postponed in the current release, but should be solved in a future release.