バグレポートの書き方
バグを正しく管理していく上で、バグレポートを正しく書くことは必要不可欠です。
バグを直してもらうために、バグレポートを登録することになりますが、このレポートが意味不明なものでは目も当てられません。
どのようなバグが見つかり、どのように直すべきなのかが簡潔に過不足なく記述されている必要があります。意味不明なレポートは開発を混乱させます。
たとえ自分で登録して直すことになるバグであったとしてもレポートは正しく記述すべきです。なぜなら、あとから必要が生じてレポートを見たときに、ソースコードに対してどんな変更を行ったのかがわからなくなってしますからです。
チームで開発しているなら、当然、他のメンバーを困惑させる要因となります。正しいバグレポートを書くことで不要なトラブルを避け、開発の生産性を向上させることができます。
漠然とした以下のようなバグレポートを書かない
-
日本語としておかしい
-
レポート内容が極端に短い
-
1つの文章が長すぎる
-
表現が抽象的
例 : 「～だったかもしれない」
-
必要な情報が示されていない
例 : 「再現手順」「発生箇所」
-
漠然としたバグレポートの弊害
- 課題の振り分けや優先度管理に支障がでる
- 開発者が混乱し、報告者への質問の手間が増える
- 報告者の意図していない箇所が修正される
- バグの発生箇所の特定が難しくなる
よいバグレポートを書くには
- レポートを読む相手のことを考えて書く
- 簡潔に書く
- 論理的に書く
- 現象・再現手順を明解に書く
あらかじめフォーマットを決めておく
::
【タイトル】
【報告者】
【優先度】
【現象】
【再現手順】
【修正方針】
タイトルを見ただけで、内容が把握できるように工夫する
例::
・ 【××画面】検索ボタン押下時エラー
・ 【××画面】削除済みのデータが一覧に表示されている
・ 【優先度:緊急】すべての画面でスタイルシートが摘要されていない
再現手順の書き方
例::
1. ××画面を表示する
2. ××のテキストフィールドに21文字入力する
3. ××ボタンを押下するとエラー画面が表示される
投稿前に文章を読み返し、誤字脱字・文章が伝わりやすいかを確認する
まとめ
- 読み手の気持ち・状況を考えて書く
- 簡潔に書く
- タイトルを見て内容が想像できる
- 再現手順が正確
- 修正方針が明確
- 複数のエラーが混在せず、問題の切り分けができている
- 投稿前に読み返す
参考文献