インシデントとは？
ソフトウェアテストの分野では、テストが期待する動作とは異なる挙動や事象で調査が必要なものをテストインシデントという。原因が究明される前の段階では必ずしも欠陥やバグとは限らない。単体テストの概要を定義したANSI/IEEE Std 1008では「調査が必要な、発生するあらゆるイベント」と定義されている。
インシデントが発生した場合
まずは現象がわかるスクリーンショット/ログを保存する
スクリーンショット、ログが必要な理由：
報告された手順通りにもしても、再現できない場合があります。
そうなった場合、本当に報告された現象が発生していたかのか？
環境や手順に報告には表現されていないミスがあり、それが原因で問題が発生していたのではないか？
と開発者に疑われかねません。
確実に報告した現象が起きていた、手順や環境に誤りがなかったというエビデンスを保存しておくこと。
## 報告上げる前に、環境設定、テストの仕方にミスがなかったか確認しよう
報告を上げたがいいが、実は環境設定ミスだったとか、テストの仕方にミスがあったとかだと、かなり恥ずかしいです。
開発者の時間を無駄に使います。
そういう事態が続くと、「どうせコイツの報告は環境設定か、手順ミスだろう」と偏見を持たれて
「まずは環境設定、テスト手順が正しいかを調べて」と調査を後回しにされてしまいます（本当にバグが発生していても）。
まずは落ち着いて、環境設定、テスト手順に誤りがなかったかを確認しましょう。
（【テスト開始前に】環境設定、テスト手順は確認しておいてから作業してください。
インシデントが発生したとき、開発者に調査する手間が発生します。
環境不正の状態でテストしても、テスト結果が信用できません。
テストはやり直しになり、ムダな工数を使います。会社にとっても迷惑です。
自分のため、周りのため、テスト開始前に環境設定を確認しましょう）
インシデントレポートの書き方
エンドユーザから「何もしてないのに壊れた」のような曖昧な問い合わせがあり、
「対象製品、バージョンは何ですか？」「そんなエラーメッセージですか？」「どういう操作したのですか？」等と
いちいち全て質問しなければならず、調査に時間がかかる場合があります。
インシデントが発生したら、「調査する開発者がどんな情報を欲しているのか」を推測して、簡潔にレポートするようにしてください。
必須項目
・対象ソフトウェア
・対象ソフトウェアのバージョン
・現象
・再現手順（実際に行った手順）
・期待した結果
・実際の結果
・再現率が100%ではない場合は、どの程度の頻度で発生するか？
簡潔に書けるのが望ましいです。
仕様理解不足で簡潔に書けない場合は、
「テスト手順書の？番の手順したらXXXになるはずがYYYになった」
でテスト手順書添付してくれればよいです。
可能な限りエラーが発生していたことが、明確に示せるスクリーンショット/ログも送付してください。
推奨項目
■動作環境
動作に影響する関連動作環境：OS、ブラウザ、前提ソフト、バージョン。
仕様書に動作環境として必要なモノが定義してあり、仕様書に合わせて環境構築してからテストするのは当然であるためか、必須項目としていないところもあるようです。
ただ、調査依頼を受けて原因を調べてみると、単なる環境設定でミスという場合も多いです。
「最低限調査依頼する前に、前提の動作環境を確認してから調査依頼出しています」ということを示しめしてもらう意味でも
調査依頼を受ける開発者としては動作環境を記載して欲しいです。
■動作について仕様書・マニュアルの記載、記載箇所
調査依頼した相手に「ちゃんと仕様書読んだのか？テスト手順書の誤りじゃねーか？よく調べろ！」といわれないように
仕様書調べたら、現象に関連する仕様書の記載内容、仕様書の記載箇所を書いておきましょう。
「テスト担当は（設計者など他の人が作った）テスト手順書通りにテストするだけ。仕様を把握・理解してなくても良い。テスト担当は調査に時間つかうな」という文化もあるので、推奨項目としておきます。
ただエンジニアとしてテストしているなら、仕様を理解した上でテストして欲しいです。
任意項目
そこまでは求めないけど、記載してあったらうれしい項目。
■ログに関する見解
最終的にエラーになった箇所、エラーのきっかけとなったエラー箇所。
エラーメッセージ、エラーコードからの推定される要因。
■原因切り分けとして行ったこと
エラーコードや現象から、原因を予測して、障害切り分けのために行ったことがあれば記載してください（別バージョンで試してみた、設定ファイルのXXを変えてみた等）。