第7章はインシデント管理。
テストにおける役割ごとに、インシデント管理で重きをおくポイントが違います。
- テスト担当者：インシデントを正しく記録する
- テストマネジャー：インシデントを管理するプロセスを実装・維持・改善する
用語集(pdf)ではインシデントは、
発生した事象の中で、調査が必要なもの (JSTQB)
とあっさり説明されていますが、（主に）テストにおいて、（主に）テスト担当者が「何か想定と違う」と感じたものと言えるでしょう。その「想定と違う」事象が、故障です。
ここで、「欠陥」と「故障」の違いを確認しておきます。 *1
JSTQBシラバス P.82
欠陥は、静的なテストにより検出することができる。故障は、動的なテストでなければ検出できない。
「タイヤがついていない」という欠陥は、車が停まっている状態でも発見することができますが、「車が走らない」という故障は、エンジンをかけて走らせようとして初めて顕在化するということですね。この「故障の認識」がインシデントです。
ただし、故障の原因である欠陥は、ソフトウェアでなくテストウェアに含まれていることもあります。テストの手順として、「エンジンをかける」という手順を踏んでいないのだとしたら、そりゃ車は走りません。タイヤがついていても。
欠陥のライフサイクルは、認識→調査→対応→処理 の4ステップとなります。
認識
インシデント発生時に、発生日・発見者・発生環境・再現手順・具体的なインシデントの内容などが記録されます。特に、インシデントがソフトウェアの使用に与える影響の大きさを評価し、調査・対応のプライオリティが決まります。
調査
インシデントが何に起因するものかを調べます。上述の通り、ソフトウェアの欠陥であるとは限らず、テストウェアの欠陥であったり、テスト担当者の手順誤りであったり、テスト環境を構成するハードウェアの問題であったりします。
対応
ソフトウェアの欠陥であれば、改修を行います。改修後は、インシデントの発生したテストアイテムを再テストするのに加え、その改修によって影響を受けるであろうソフトウェアの範囲の再テストと回帰テストが必要になります。
また、当該の欠陥を単なる一過性の間違いとせず、同様の欠陥が他にないか、同種の欠陥を今後未然に防ぐにはどうすればいいかの検討を行ないます。
処理
必要な情報を追記したうえで、当該のインシデントをクローズします。クローズできない場合は、先送りしたり、他プロジェクトへ移管したりすることになります。
記録されるべきインシデントの情報については、IEEE1044-1993に規定されています。中身を読めていないのですが、「これこれは記録すべし」という標準は、組織でもっていることが多いのでしょうね。わたし自身、自分なりの標準を持っています。
どうしてもたくさんのデータを集めたくなるのですが、記録する方にとっては少ないに越したことはない。テスト担当者なら早く次のアイテムに移りたいし、コーディング担当者がテスト担当を兼ねている場合は、記録している暇があればさっさと直したい・・・ですよね。
しかし、インシデントの記録は品質測定と品質向上のための大切なネタ。テストマネジャーとしては、最低限の手間で最大限の情報を取り出せるようなバランスを見出したいものですね。
もう1つ、大切なこと。
インシデントの記録を書くテスト担当者にとっても、書かれる設計・実装担当者にとっても、個人攻撃になることを恐れるようなチーム・文化にならないよう、注意！
*1:言葉の定義についてはコチラの記事もご参照ください。 www.kzsuzuki.com
