 |
| |
ISTQB Advanced Level Syllabi
7. Incident Management
Terms
IEEE 829, IEEE 1044, IEEE 1044.1, anomaly, configuration control board, defect, error, failure, incident, incident logging, priority, root cause analysis, severity
Test managers, and testers must be familiar with the defect management process. Test managers focus on the process, including methods to recognize, track and remove defects. Testers are primarily concerned with accurately recording issues found in their test areas. For each of the steps in the lifecycle, test analysts and technical test analysts will have a different orientation. Test analysts will evaluate the behavior in terms of business and user needs, e.g., would the user know what to do when faced with this message or behavior. The technical test analysts will be evaluating the behavior of the software itself and will likely do more technical investigation of the problem, e.g., testing the same failure on different platforms or with different memory configurations.
7.2 When can a Defect be detected?
An incident is an unexpected occurrence that requires further investigation. An incident is the recognition of a failure caused by a defect. An incident may or may not result in the generation of a defect report. A defect is an actual problem that has been determined to require resolution by changing the work item.
A defect can be detected through static testing. A failure can be detected only through dynamictesting. Each phase of the Software Life Cycle should provide a method for detecting and eliminating potential failures. For example, during the development phase, code and design reviews should be used to detect defects. During dynamic test, test cases are used to detect failures. The earlier a defect is detected and corrected, the lower the cost of quality for the system as a whole. It should be remembered that defects can exist in testware as well as in the test object.
All defects have a lifecycle, although some may skip some stages. The defect lifecycle (as described in IEEE 1044-1993) is composed of four steps:
Within each step are three information capture activities:
The Recognition step occurs when a potential defect (incident) is discovered. This can occur in any phase of the Software Life Cycle. At the time of discovery, the data items that identify the defect are recorded. This includes such information as the environment in which the defect was observed, the originator, the description information, the time and the vendor (if applicable). The recognition is classified by identifying certain attributes of the potential defect, including project activity, project phase, suspected cause, repeatability, symptom(s) and product status as a result of the anomaly. With this information, the impact is assessed by rating the severity, project schedule impact and project cost impact.
After Recognition, each potential defect is investigated. This step is primarily used to find any related issues and propose solutions, which may include no action (e.g. potential defect is no longer considered an actual defect). Additional data is recorded at this step as well as a re-evaluation of the classification and impact information supplied in the previous step.
Based on the results of the Investigation, the Action step commences. Actions include those required to resolve the defect as well as any actions indicated for revising/improving processes and policies in order to prevent future similar defects. Regression testing and retesting, as well as progression testing must be performed for each change. Additional data is recorded at this step as well as a re-evaluation of the classification and impact information supplied in the previous step.
The anomaly then moves to the Disposition step where any additional data items are recorded and the disposition classification is set to either closed, deferred, merged or referred to another project.
IEEE 1044-1993 specifies a set of mandatory fields that are set at various times in the defect's lifecycle. A large set of optional fields is also defined. According to IEEE 1044.1, when implementing IEEE 1044-1993, it is acceptable to create a mapping between the IEEE terms for defect fields and the associated names used by an individual company. This allows conformance with IEEE 1044-1993 without have to tightly adhere to the naming conventions. IEEE conformance allows comparison of defect information across multiple companies and organizations.
Regardless of whether IEEE conformance is a goal, the fields supplied for a defect are intended to provide enough information so the defect is actionable. An actionable defect report is:
In addition to resolving the specific defect, information must also be supplied for accurate classification, risk analysis, and process improvement.
7.5 Metrics & Incident Management
Defect information needs to include enough information to assist in test progress monitoring, defect density analysis, found vs. fixed metrics and convergence metrics (open vs. closed). In addition, defect information needs to support process improvement initiatives by tracking phase containment information, root cause analysis and identifying defect trends to be used as input to strategic risk mitigation adjustments.
Incident management includes effective communication that is free from accusations and supports the gathering and interpretation of objective information. The accuracy of the incident reports, proper classification and demonstrated objectivity are imperative to maintain professional relations among the people reporting defects and the people resolving the defects. Testers may be consulted regarding the relative importance of a defect and should provide available objective information.
Defect triage meetings may be conducted to assist in proper prioritization. A defect tracking tool should not be used as a substitute for good communication nor should triage meetings be used as a substitute for not using a good defect tracking tool. Both communication and adequate tool support are necessary for an effective defect process.