ソフトウェア開発は高い品質の製品を提供するために多くの労力を使います。世の中にリリースしたアプリケーションやシステムにバグがあってはなりません。システムは業界によっては、人命に関わる重大なバグから機能的には影響ない軽微なバグまで様々なバグが発生しています。理想はバグをすべて発見し修正することですが、完全にバグのないソフトウェアを作ることはほぼ不可能です。どうしてもテストチームで見つけることができないバグは存在しています。

開発チームはすべてのバグを修正するという使命があると考えています。また、開発したアプリケーションやシステムの利用者に迷惑をかけたく無いとも考えています。 だからこそバグを見つけたときは開発者にとって有益な報告をしてもらえるよう、良いバグレポートに必要なことをまとめました。

良いバグレポートのメリットは、開発者が問題を見つける大きなヒントを提供してくれます。同じ問題をすぐに再現させることができ、原因の特定に時間がかかりません。バグは原因が分かってしまえば解決することは比較的簡単にできることが多いです。

このエントリーでは、テストチームやアプリケーション利用者が開発者に良いバグレポートを作成するための必要な情報について説明します。

 

良いバグレポートに必要なこと

 

以下の5つをバグレポートに含める必要があります。バグを見つけたとき感情的になることがあります。でも深呼吸して落ち着いてからバグレポートのルールを思い出してください。そのルールは「事実をありのままに伝える」です。

1. タイトル

 

「簡潔で問題がわかる要約として記述すること」

理想的なバグレポートのタイトルは、簡潔で問題が発生した状況が含まれていると良いです。

2. 現象

 

「どのようなバグが発生したのか、できるだけ詳細に記述すること」

利用している環境（ブラウザの種類やOSの種類、バージョン）、表示されているエラー番号や画面の情報、などできるだけ詳しく書くことをオススメします。

3. 再現手順

 

「そのバグを再現するための手順をできるだけ詳しく記述すること」

バグが発生したとき、できるだけ早期に原因を特定するために必ず必要です。

バグ発生手順を順番に説明してください。また、再現性：100％再現しますか、それとも10回に1回くらいの頻度でしょうか。

4. 期待される事象

 

「どのような結果を期待しているのかを記述すること」

バグと判断しチケットを作成した人が期待していることを示さなければ、なぜそれがバグであるのか担当者は理解できないことがあります。このバグが起こらなかった場合の期待される事象を記述してください。

5. 障害発生時に観察されたこと

 

「バグが起こったことで、どのようなことが起こったのか？を記述すること。」

エラーが表示されましたか？そのエラーの内容は何でしょうか。別のアプリケーションを使っていましたか。

追加の情報

 

• アプリケーションやシステムログを提供できる場合、ぜひバグレポートに追加してください。
• 画面のスクリーンショットが提供できる場合、言葉以上に効果的な報告が可能です。
• 画面に表示されたエラー情報がある場合、忘れずにバグレポートに追加してください。