5.6 インシデント管理

5.6.1 インシデントとは

「発生した事象の中で、調査が必要なもの」

つまり、「期待結果と違うもの」

テストだけに発生せず、開発中、レビュー、システム稼動中にも現れる

コードの欠陥として現れるだけでなく、あらゆる種類のドキュメントでも発生する

5.6.2 インシデント管理の必要性

対応終了までのステップ

1. インシデントが発生したことを認識する

2. インシデントを記録する

3. インシデントの原因を調査する

4. 影響範囲を分析し、インシデントを分類する

5. 修正が完了するまで待機する

6. 修正が終わったことを確認する

組織でインシデント管理のプロセスを決め、分類のための規則を儲ける必要がある

5.6.3 インシデントの記録

インシデントを記録するのはテスト担当だけじゃない

顧客が期待した結果と動作が違うと感じたら、それがインシデント

5.6.4 インシデントレポートの目的

発生したあらゆるインシデントを報告するドキュメント

目的は

5.6.5 インシデントレポートの構成

1. テストインシデントレポート識別番号

2. 概要

3. 詳細

ログの作成日付、作成組織、作成者、承認、現在の状態

期待した結果と実際の結果

インシデントを検出した日付

インシデントが発生したソフトウェアやシステムのライフサイクルプロセス

不正現象の詳細な説明

4. 影響範囲

システム与えるインパクト（システムの他の機能に不都合を与えるかなど）

修正することで別部署などへ及ぼす影響

修正の緊急度、優先順位

インシデントの現状

未解決、次バージョンへ延期、重複、修正待ち、検証待ち、解決済

要はステータス

結論とアドバイス

修正履歴

5.6.6 インシデント管理のプロセス

オープン

解決に着手

分析・割当

却下

情報が足りなかった、誤っているなどで調査できない場合はレポートを却下する

再テスト

失敗

テストがうまくいかない、問題が解決されていない場合は差し戻す

クローズ

インシデントレポートを閉じる