INCIDENT MANAGEMENT

An incident is any unplanned event occurring that requires further investigation. In testing this translates into anything where the actual result is different to the expected result. An incident when investigated may be a defect, however, it may also be a change to a specification or an issue with the test being run. It is important that a process exists to track all incidents through to closure.

Incidents can be raised at any time throughout the software development life cycle, from reviews of the test basis (requirements, specifications, etc.) to test specification and test execution.

Incident management, according to IEEE 1044 (Standard Classification for Software Anomalies), is ‘The process of recognising, investigating, taking action and disposing of incidents.‘ It involves recording incidents, classifying them and identifying the impact. The process of incident management ensures that incidents are tracked from recognition to correction, and finally through retest and closure. It is important that organisations document their incident management process and ensure they have appointed someone (often called an incident manager/coordinator) to manage/police the process.

Incidents are raised on incident reports, either electronically via an incident management system (from Microsoft Excel to sophisticated incident management tools) or on paper. Incident reports have the following objectives:

• To provide developers and other parties with feedback on the problem to enable identification, isolation and correction as necessary. It must be remembered that most developers and other parties who will correct the defect or clear up any confusion will not be present at the point of identification, so without full and concise information they will be unable to understand the problem, and possibly therefore unable to understand how to go about fixing it. The more information provided, the better.

• To provide test leaders with a means of tracking the quality of the system under test and the progress of the testing. One of the key metrics used to measure progress is a view of how many incidents are raised, their priority and finally that they have been corrected and signed off.

• To provide ideas for test process improvement. For each incident the point of injection should be documented, e.g. a defect in requirements or code, and subsequent process improvement can focus on that particular area to stop the same defect occurring again.

The details that are normally included on an incident report are:

• Date of issue, issuing organisation, author, approvals and status.

• Scope, severity and priority of the incident.

• References, including the identity of the test case specification that revealed the problem.

• Expected and actual results.

• Date the incident was discovered.

• Identification of the test item (configuration item) and environment.

• Software or system life-cycle process in which the incident was observed.

• Description of the incident to enable reproduction and resolution, including logs, database dumps or screenshots.

• Degree of impact on stakeholder(s) interests.

• Severity of the impact on the system.

• Urgency/priority to fix.

• Status of the incident (e.g. open, deferred, duplicate, waiting to be fixed, fixed awaiting confirmation test or closed).

• Conclusions, recommendations and approvals.

• Global issues, such as other areas that may be affected by a change resulting from the incident.

• Change history, such as the sequence of actions taken by project team members with respect to the incident to isolate, repair and confirm it as fixed.

The syllabus also recognises that IEEE 829 contains the outline of a test incident report. The outline suggests that the report should contain the sections shown in Table 5.4.