タイミング情報：いつインシデントが観測されたかを記述する

作成者：誰がインシデントを確認したかを記述する

状況：どこでインシデントを確認したかを記述する

インシデントの説明：気づいた点やエビデンスを記述する

作成者による重要度の評価：インシデントがユーザーおよびビジネスに及ぼすインパクトの程度を記述する

作成者による優先度の評価：どのくらいの緊急度で修正が必要かを記述する

リスク：新規に検出したリスクか、既存のリスク対応によるエンバグかを記述する

インシデントのステータス：インシデントの現在の状態を記述する


上記項目の内容については、以下の資料より一部抜粋編集して記載しています。

※参照
ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書
著：Stuart Reid

1.タイミング情報

対象インシデントがいつ検出されたかの日時を明示することで、以降の経過日数や開発プロダクトに対する対応期限などの管理を可能にします。

2.作成者

報告したチケットの担当者を記載します。

iso/iec/ieee 29119規格遵守の必須項目では作成者としていますが、より拡張的な対応として、作成者の他にインシデントの現時点担当者も記載することで、そのインシデントは現在誰が対応管理しているのかを確認できるため、未対応なのか、対応中なのか、既に対応完了して履歴として残している段階なのかなどを把握することができます。

3.状況

チケットを何のテストで検出したかにもよりますが、テスト対象の機能に関する不具合なのか、仕様書などのテスト対象関連アイテム内の不具合に関係するものかを記載します。

修正・確認の際に必要な再現性を確保するため、テスト環境と構成の情報を記載します。

また、後述のインシデントの説明項目に含まれる場合がありますが、テスト手順とテストケース詳細をこの状況項目に含むこともあります。

4.インシデントの説明

不具合自体の説明を記載します。

状況の項目にテスト手順を記載する場合があると記載しましたが、特定手順でのみ再現するインシデント自体を説明する上では、手順を併せて参照する必要があるため、手順もインシデント説明の内容として当該項目に含めます。

また、インシデントには取得可能なものは必ずエビデンス(証跡)を添付します。

ソフトウェアテスト動作に対する不具合のエビデンスであれば、動作させている画面のスクリーンショットあるいは動画を添付します。

画面として出力されない部分での不具合については、エビデンスとして動作ログなどを添付する場合もあります。

5.作成者による重要度の評価

不具合を検出報告したチケット作成者が、検出した内容に応じて重要度を設定します。

あくまでテスト側が検出した不具合内容に応じて判定するので、その後、実装担当者が修正対応する際に解析した結果として、重要度が更新変更される場合もありますが、報告時はテスト側の視点でどれほど影響があるかとして判定します。

重要度もプロジェクトにより独自にレベルが設定されている場合がありますが、大抵の場合は以下の3段階程度で評価されます。

　・クリティカル
　サービス使用不可能になる程度の重大な不具合であり、即時対応必須の緊急性があるレベル。

　確定的なアプリケーションのクラッシュや、ユーザーとプロジェクトに金銭的不利益が発生するものなどが該当する。

　・メジャー
　クリティカルよりも程度は低いものの、リリース前には修正されていなければならないと想定されるレベル。

　ユーザー不満によりサービス品質評価のダウンが想定されるもの。

　おおよその不具合はこのレベルに分類される場合が多い。

　・マイナー
　メジャーよりもさらに程度が低く、ユーザーへの影響がほとんどないと思われるレベル。

　仕様の取り違えにはつながらない程度の誤字脱字や、機能の可用性には関わらない程度の表示崩れ、発生方法はあるが再現性が低かったり、故意に再現させたとしても機能を改ざん悪用したりはできないようなものなど、例え修正されずにリリースとなったとしてもサービス・ユーザー双方に影響がない想定のため、修正対応見送り