前回の「テストの管理Vol.5　〜テストで考慮すべき２つのリスク〜」では、そもそもテストにおけるリスクの定義から、プロジェクトリスクとプロダクトリスクの詳細について解説しました。今回は、テストにおけるインシデントと、その管理方法についてご紹介します。

テストにおける「インシデント」とは

インシデントとは、状況や立場によってさまざまな定義に分かれますが、テストにおけるインシデントとは、JSTQBでは以下のように定義されています。

引用：発生した事象の中で、調査が必要なもの。

では、具体的に「調査が必要なもの」とは、どのようなものを指すのでしょうか。それは「期待した結果と異なる結果が得られたもの」を指します。また、インシデントと聞くと「バグに結びつく危険な存在」として認識されがちですが、あくまでも調査が必要なものであり、それ自体が悪い存在というわけではありません。

また、インシデントはテストだけでなく、開発段階からレビューの段階、そして実際に稼働している最中にも発生するものです。ここで見落としがちなのが、インシデントとはソフトウェアの挙動やソースコードの欠陥として現れるだけでなく、開発やテストのドキュメントといったテキストの中でも発生しうるものです。

インシデント管理の流れ

なぜテストにおけるインシデントには管理が必要なのでしょうか。まず、テストでインシデントが発生した場合、速やかに調査をおこない、それらがバグや欠陥に結びついていないか確認する必要があります。そして、それらがバグや欠陥と認識された場合、修正の対応が必要になります。そうなった場合、最初にインシデントが見つかってから、バグが修正されるまでの間、すべての情報にアクセスできる状況を作っておく必要があります。そのために管理が重要なのです。

テストにおけるインシデント管理のステップは、概ね以下のようになっています。

インシデントの記録

インシデントを管理するためには、発生したインシデントをすべて記録しておかなければなりません。しかし、このときに意識しなければいけないのが、インシデントを記録するのはテストを担当する人だけではないということです。

開発段階で見つかればエンジニアから、リリース後に見つかればユーザーや顧客からインシデントを記録することになります。そのため、インシデントがすべてソースコードの欠陥になるかというとそうではありません。

インシデントレポート

発生したすべてのインシデントを報告するドキュメントを「インシデントレポート」と呼びます。

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

インシデントレポートを作成する目的には、以下のようなものがあります。

特に、開発に対してインシデントの情報を提供するというのは分かりやすい目的だと思います。インシデントがバグや欠陥に結びついていないか調査し、もしバグや欠陥であった場合には修正してもらう必要があるからです。

また、インシデントレポートはテスト管理者にとっても重要な情報を提供してくれます。インシデントの数や状況によりテスト対象の品質が分かり、同時にテストの進捗やその後の実施計画の判断材料にもなるためです。

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

インシデントレポートには、以下の項目を記載しておくことで管理に必要な情報が網羅できるようになります。

それぞれ、どのようなことを記載すればいいのか見ていきましょう。

（１）インシデントレポートの識別番号

インシデントレポートに付ける文書番号のことで、あとから参照できるように一意で管理されている必要があります。

（２）インシデントの概要

発生したインシデントの内容を簡潔にまとめます。ここまでは、実際に修正などを行うひと以外も目を通すことを意識しておきましょう。

（３）インシデントの詳細

ここからはインシデントを実際に修正する人が見るため、できるだけ詳細にインシデントの内容を伝える必要があります。ログの作成日時から、作成者や現在のステータス、インシデントを検出したテストとの紐付け、期待した結果と実際の結果、その他にもインシデントを検出したテストアイテムの情報なども記載しておくといいでしょう。「よくわからない現象」について的確に伝えることが重要です。

（４）影響範囲

影響範囲には「どのインシデントから解決すべきか」を判断するための大変重要な情報が揃っています。まずインシデントの範囲や重要度、優先順位があります。次にステークホルダーに対してどのような影響を与えるのか。最後に他の機能への不都合やバグを引き継ぐことがないかです。

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

インシデント管理のプロセスには「インシデントレポートの状態遷移に着目したプロセス」と「ワークフローに着目したプロセス」の2つがあり、それぞれにメリット・デメリットが存在しますが、ここではインシデントレポート状態遷移に着目したプロセスをご紹介します。

オープン

インシデントレポートの解決に着手したことを表します。

分析・割当

インシデントレポートの内容を分析し、必要な担当者にレポートを割り当てて修正を行います。

却下

開発担当者がインシデントを調査できない内容（情報不足や、誤った情報）だった場合にはレポートを却下します。

再テスト

問題箇所の修正が完了したら、インシデントが再発しないか確認のためのテストを行います。

失敗

確認のためのテストが失敗した（問題が解決されなかった）ときは、テストの失敗として、担当者へと差戻します。

クローズ

確認のためのテストに問題がなく、インシデントは解決されたと判断した場合、インシデントレポートをクローズします。

まとめ

ここまで、テストにおけるインシデントと、インシデントレポートを用いた管理方法についてご紹介しました。

■テスト・検証に関する課題解決はお任せ下さい

弊社は、webサイトやスマホアプリ、クラウド製品、業務システムなどのソフトウェアにおけるテスト・検証を支援する、第三者検証サービスを提供しております。テスト管理に限らず、テスト・検証に関する課題がございましたら、お気軽にお問い合わせください。

■テストの管理に関するその他の解説記事

【参考文献】：
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』