# Incident management
###### tags: `ISTQB` `SQA`
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.==

==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.

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.
:::info
找到bug的時候，通常開發者或其他成員不會在這個階段，所以要留下足夠完整的資訊，才能幫助他們解決問題。
:::
- To provide test leaders with a means of tracking the quality of the system under test and the progress of the testing.

- To provide ideas for test process improvement.
For each incident the point of injection should be documented, for example 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 stakeholders’ 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.