[ISTQB] 5.6 Incident Management (K3)

Incident management is the process of recognizing, investigating, taking action, and disposing of incidents. It involves logging incident, classifying item and identifying the impact.

LO-5.6.1 Recognize the content of an incident report according to the 'Standard for Software Test Documentation' (IEEE Std 829-1998) (K1)

An incident report should detail:
  • date of issue
  • organisation and author
  • expected and actual results
  • identification of test item and environment involved
  • software or system life cycle process in which the incident was observed, 
  • description of the anomaly and how to reproduce it
  • scope or degree of impact on stakeholders interest
  • severity of the impact on the system, urgency/priority to fix
  • status of the incident
  • conclusions
  • recommendation, approvals, global issues
  • change history.

- They provide feedback about issues encountered to development team and others.
- They facilitate identification, isolation and correction. 
- They are used by the test leader or test manager in test reporting and monitoring (number of defects created, severity...).

Finally and according to the structure standardized by IEEE 829-1998, an incident report should include: 
  • incident report id
  • summary
  • incident description with input
  • expected results, anomaly, 
  • date and time
  • procedure
  • environment
  • attempts to repeat
  • tester
  • observer
  • impact.

LO-5.6.2 Write an incident report covering the observation of a failure during testing (K3) 

Recognition, Investigation (problem analysis), Action (problem fixed), Disposition (fix verified) are the 4 stages stated in incident management. 

An incident report ensure traceability and classification of the issue or defect found.

No comments:

Post a Comment

Wikipedia

Search results