書き方によっては報告者と開発者が対立関係に陥ってしまいかねないので、バグレポートは書き方次第でプロジェクトの行く末を左右します。
プログラミング経験がある報告者もない報告者もこれだけは抑えてもらいたい、伝わりやすいバグレポートを書くための3つのステップを解説します。
1. 現象（バグの内容を具体的に記す）
バグレポートはどういったバグが発生しているのか相手に正しく伝えることが第一のステップです。問題の現象を具体的に記すること、これを怠ると次のステップに進めません。
1件のバグレポートに複数のバグをまとめると追跡がしにくくなるので、1つのバグにつき1つのバグレポートで報告します。
「投稿画面で画像のアップロードに失敗する」「問い合わせメール送信後のレイアウトが崩れる」などバグの内容を具体的に記します。
バグやエラーが起きた状態をスクリーンショットで添付しておくと、よりバグの内容が伝わりやすいです。
その際、ブラウザやアプリケーションの種類、OSのバージョンなど実行環境も必ず記しておきましょう。
特定のブラウザでレイアウトが崩れる場合、実行環境が書かれていないとバグを再現・修正できません。
2. 期待する結果（バグの修正内容）
バグをどのように修正して欲しいのか、報告者が期待する結果を記します。仕様である場合、バグと認められないことがあるため、どう修正して欲しいのかを明確に記す必要があります。
バスの修正によってどのような結果になることを期待しているのか、ここが明確でなければまたバグレポートを書くことになったり、バグと認められず修正されません。
3. 再現手順
次にどういった操作をした時にバグが発生するのかなど、具体的な再現手順を記します。ステップ1の現象の報告だけでは厳密にエラーが起きる手順がわからないので、バグが発生するまでに行った手順を記す必要があります。
再現手順は具体的に、かつ余計な表現は使わずわかりやすく再現手順を記しましょう。
各手順を箇条書きにして記すと相手に伝わりやすいです。
現象を具体的に書いているのにバグレポートが戻された場合、再現手順が書かれていないことが原因として考えられます。
バグレポートを書く上で大切なこと
バグレポートは、「バグが起こってるじゃないか」と相手に伝えるだけでなく、どういった状況下でバグが起こるのか、どうバグを修正して欲しいのか、そしてどうやってそのバグが再現できるのか、この3つのステップが肝になります。報告者本人だけがわかる内容では、バグレポートは役に立ちません。
プログラミング経験者でない場合、バグレポートをあいまいに記してしまうことが多いですが、不明確なバグレポートはお互いの時間をロスしてしまいます。
「投稿画面でエラーが出た」といった具体的でない表現や、「レイアウトがおかしい」といった、捉え方によってはプログラマの自尊心を傷つけかねないような書き方は良くありません。
バグレポートは報告者と開発者の橋渡しになる存在であるため、読み手のことを考えて書くことが大事です。
余計な一言は書かない
バグレポートに「それぐらいはやってもらいたいです」「どうしてこうなるのか理解できません」といった余計な一言書いていませんか？バグが起こったことに対する不満があるのかもしれませんが、これを読んだプログラマやエンジニアはどう思うでしょうか？
たとえ、開発者のミスであったとしても、余計な一言を書いたことが原因で関係が悪化してしまいかねせん。
報告者 VS 開発者という対立関係が生まれるのは、間違ったバグレポートが原因のひとつです。
言わなくてもいいことは、わざわざバグレポートに書く必要がありません。
開発者側も「意味がわかりません」「バグじゃないです」など、はなから聞く耳を持たない態度をとってしまっては関係が悪化してしまいます。
特にプログラミング未経験者はどうバグレポートを書いたらいいのかわからないので、具体的にどう書いて欲しいのかを丁寧に返答し、フォーマットがあればそれを提供するなど、お互い歩み寄る姿勢が大切です。
バグレポートは開発者に不満をぶつけるためのものではなく、制作物にするためのものです。
お互いが良い協力関係を維持するためには、バグレポートの読み手のことを考えて書きましょう。
