欠陥レポートを書くときの注意点

欠陥レポートは不具合を開発担当者に伝えるためのコミュニケーションツールです。不具合の様子が正確に描写されるというのは不可欠な要素ですが、正確なだけではありません。欠陥レポートを受け取る相手にとって理解しやすいものでなければなりません。

全体を通して欠陥レポートを書くときの注意

• 1不具合1レポートの原則
  一つの不具合を複数の欠陥レポートで報告したり、複数の不具合を一つの欠陥レポートで報告したりすれば、正確な不具合の数を知ることができなくなります。同一の操作で導かれた不具合であっても、複数の不具合と言える場合は、それぞれ別の欠陥レポートで起票します。

• 欠陥レポートはコミュニケーションツール
  　テスト実施をしていると「こんな不具合を作り込むなんて真面目に仕事してないんじゃないか？」と訝死んでしまうような不具合に出会うことがあります。しかし、開発担当者もふざけてそのように製造したわけではないのです。差し迫る納期や度重なる仕様変更に耐えながら、必死の思いで政治した結果として現れた不具合なのです。
  ですから、決してこれを馬鹿にしてはいけません。テストオペレーターと開発担当者はより良いソフトウェアを作っていくための仲間です。欠陥レポートには相手を不当に非難するような感情的なコメントを書き込んではいけません。

欠陥管理情報

• タイトルは分かりやすく
  　欠陥レポートのタイトルは、不具合がどんな様子なのか一目わかるタイトルでなければいけません。開発担当者は非常に忙しいことがほとんどです。分かりにくいタイトルはソフトウェアの修正の効率を下げてしまいます。
  また、分かりやすいタイトルは不具合の検索や分類のしやすさを向上します。
• 重度設定は適切には分かりやすく
  　開発担当者に、検出した不具合をできるだけ早く気づいてもらおうとして、重要度を高めに設定してしまうテストオペレーターがいます。しかしこれは避けなければなりません。どれも皆高い重要度にしてしまうと、本当に重要度の高いものと、そうでないものの区別がつかなくり、この細目を設けた意味がなくなってしまいます。

欠陥の内容を書くときの注意

• 発生手順は一操作ごとに箇条書きで
  　発生手順はどのような操作をすれば不具合が発生するのか具体的に記載したものです。通常１手順ごとに箇条書きの形式で記載します。一つの過剰に複数の手順を記載してはいけません。
• 再現率は分数の形式で
  　10回同じ操作して10河合とも不具合が発生したとしたら、再現率100%と描きたくなってしまいますよね。しかしそれは望ましくありません。
  この書き方で実施した回数と不具合が発生した回数の割合しかわからず、実感がわからないです。再現率は「発生回数/実施回数」（今回の場合は10/10）と書くのが良いでしょう。

動作環境情報を書くときの注意

• 前の準備・確認が重要
  　プロジェクトごとに仕様機材やOS等は異なります。またプロジェクトが動いている最中にもこれらは変更されることがあります。
  あらかじめ、どのような情報が必要なのか調査するだけでなく、不明点があった場合は、現場のリーダーに必ず質問し、不明点を解消してから記入しましょう。

備考を書くときの注意

• 項目にないことは書かなくていいや・・・はだめ
  テンプレートの項目にはないことでも、重要だと考えられることは「備考」に記載しましょう。開発担当者がソフトウェアを修正する際のヒントとなるはずです。
  具体的には・・・

1. 不具合の発生しない場合や回避方法
2. デグレード（修正によって他の部分に不具合が発生すること）の有無
3. 関連するテストケースのID
4. 類似の不具合を記載した欠陥レポートのID
5. 同じ操作で発生した別の不具合を記載した欠陥レポートのID
   などを記載します。

エビデンスの取得と添付の注意

• 不具合部分の明示
  首都きした画像のどの部分が不具合であるのか、矢印や枠線を書き込んだり、不具合発生までの流れがわかるように順番に添付するなどして、何が不具合であるのかをはっきりさせましょう。
• エビデンスの格納方法
  　取得したエビデンスを開発担当者に届ける方法には、欠陥レポートのファイルに張り込むように添付する方法以外に、別の場所に格納することで提出するという方法もあります。

まとめ

• 欠陥レポートは分かりやすく。
• 欠陥レポートは正確に。