5.6 Incident management (K3)

Some definitions of an incident :
§ An incident is any nonconformity in a product or process. Anything that does not conform to the product specifications is an incident.
§ A discrepancy between a test case and the product requirements, design, or implementation. Incidents can also occur in the test case itself.
§ A flaw in a system or system component that causes the system or component to fail to perform its required function. An incident, if encountered during execution, may cause a failure of the system
§ A product's or service's non-fulfillment of an intended requirement or reasonable expectation for use, including safety considerations.

Since one of the objectives of testing is to find defects, the discrepancies between actual and
expected outcomes need to be logged as incidents. Incidents should be tracked from discovery and classification to correction and confirmation of the solution. In order to manage all incidents to completion, an organization should establish a process and rules for classification.
Incidents may be raised during development, review, testing or use of a software product. They may be raised for issues in code or the working system, or in any type of documentation including requirements, development documents, test documents and user information such as “Help” or installation guides.

Incident reports have the following objectives:
§ Provide developers and other parties with feedback about the problem to enable identification, isolation and correction as necessary.
§ Provide test leaders a means of tracking the quality of the system under test and the progress of the testing.
§ Provide ideas for test process improvement.

Details of the incident report may include:
§ Date of issue, issuing organization, and author.
§ Expected and actual results.
§ 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.
§ Scope or degree of impact on stakeholder(s) interests.
§ 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 re test closed).
§ Conclusions and 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.
§ References, including the identity of the test case specification that revealed the problem.

The structure of an incident report is also covered in the ‘Standard for Software Test Documentation’ (IEEE 829).


Post a Comment