欠陥レポートの中身
欠陥レポートは不具合の様子を開発担当者に伝えるためのコミュニケーションの手段です。テスト実施している私たちのメモ書きではありません。相手によりよく意図を伝えるにはどのような書き方が適切だろうかと常に自問自答することで、結果レポートはいいものになっていきます。
欠陥レポートの中身
欠陥レポートは、どのような不具合が、どのような条件や手順で発生したのか、開発担当者に伝えるためのドキュメントです。基本的に一つの不具合に対して一つの欠陥レポートを起票します。
欠陥管理情報
欠陥レポートを管理するための項目です。欠陥レポート同士を区別し、おおよその内容を明らかにし、重要度を示している部分です。具体的には次のような細目から構成されることが多いでしょう。
- タイトル
どのような不具合が発生したのか一目でわかるよう簡潔に表したもの。短すぎても長すぎてもいけません。 - 欠陥管理ID
欠陥レポートそれぞれに与えられた固有の番号。これにより欠陥レポート同士を間違えることは無くなります。 - テストケースID
どのテストケースを実施した際に検出した不具合であるのかを明治するための細目。欠陥レポートとテストケースとの間のトレーサビリティ（追跡する能力)を確保します。テストケース外で検出した場合はその旨を記載します。 - 起票者名
不具合を検出し、欠陥レポートを作成したテストオペレーターの氏名。 - 起票日時
欠陥を検出した日時と時刻。 - 重要度
不具合のリスクの高さを数段階に分けて(例えばA>B>C・・・のように)記載します。開発担当者はこの記載を参考に、どの不具合から修正すべきか優先順位をつけます。全て、高重要度（あるいは低重要度）のような記載にしてしまうと役立たない細目となってしまいます。
欠陥の内容
- 概要
どのような不具合が発生したのか、要約した情報を記載します。 - 発生手順
不具合が発生した際の操作手順を記載します。一つの文には複数の手順を記述せず、原則的に慰問一手順として記載します。 - 動作結果
「発生手順」を実施した結果をそのまま記載します。これが不具合の症状そのものとなるわけですが、それを強調した表現にする必要はありません。なぜなら、次の細目である「期待結果」と比較することで、充分に明らかになるからです。 - 期待結果
テストケースに記載された「期待結果」を転記します。テストケース外である場合は、機能仕様書やユーザーの要求から期待される理想としての挙動を記載しましょう。 - 再現率
- テストを実施した回数と、そのうち不具合が発生した回数を記します。テストを３回実施した際、不具合が２回発生したのなら「2/3」のように分数で記載します。
動作環境情報
テスト対象がどのようなものだったか、どのような環境で動作したかを記録したもの。この記載によって開発担当者はテスト実施時の状態を把握することができます。
- テスト対象の名称・バージョン
テスト対象のソフトウェアの名称とそのバージョンを記載します。 - 期待の種類・バージョン
PCや携帯などの機体の種類（型番）とそのバージョンを記載します。 - OSの種類・バージョン
PCや携帯などの機体に搭載されているOSの種類とそのバージョンを記載します。
備考
項目にない追加情報や補足を記載します。関連ある不具合について（類似の事象や同じ操作で検出された不具合の情報など）や不具合の回避情報などもこちらに記載します。また欠陥管理情報や動作環境情報の一部がこちらに記載されていることもしばしばあります。
エビデンス
不具合の証拠となる画像や動画を欠陥レポートに添付します。エビデンスの画像は、正とされる画像と比較できるよう配置したり、矢印や枠線を設けたり、時系列で並べたりするなど、どの点が不具合であるのか開発担当者の理解できるよう工夫して添付しましょう。
まとめ
- 欠陥レポートはコミュニケーションの手段
- 欠陥レポートは、不具合の発生する条件・手順などを開発担当者に伝えるためのドキュメント
- 欠陥レポートは「欠陥管理情報」 「欠陥の内容」 「動作環境情報」 「備考」 「エビデンス」で構成されていることが多い。