バグレポートの使い方

ソフトウェアには必ず「バグ」があります。場合によって「不具合」「設計上の副作用」などと別の呼び方をされることがありますが、ともかく絶対にバグとは無縁でいられません。つまり、プロジェクトを円滑に進める上で、バグレポートの作成が不可欠になるということです。バグレポートには何が求められるのか、どのように書けばいいのかを知っておくのはとても重要なのです。

バグレポートには、必ず次の3つのことを書く必要があります。

• バグの再現方法(できるだけ詐しく)と発生頻度
• 本来の仕様(バグがない場合の望ましい動作。こうあるべき、という自分の意見でかまわない)
• 実際の動作(完全でなくても、自分の記録した範囲で詳しく書く)

バグレポートはもちろん、バグについて伝えるものですが、レポートを見れば、書いたのがどういう人かも同時に伝わります。詳細で、質の良いレポートを書けば、自分の評価も高まるでしょう。ぶっきらぼうに、怒りをぶちまけただけのレポート(「この関数は最低!」などとしか書いてない)では、人格を疑われることにもなります。書いた人間がとても不機嫌であることは伝わりますが、ほとんど何の役にも立ちません。状況が詳しく説明され、バグが容易に再現できるよう配慮されたレポートならば、逆に皆の尊敬を集めるはずです。たとえそれで、リリースができなくなっても、恨まれることはないでしょう。

バグレポートを作成するのは、誰かと対話するためです。対話をするためには、そのバグが発生するにいたる過程をすべて相手に知らせる必要があります。同じ情報を共有しなくては対話にならないからです。バグレポートは、決して誰かを責めたり、バグが存在するコードを批判したりするためのものではありません。バグについて、より多くの情報を得ること、自分の知らなかったことを知ること、それがバグレポートの目的です。

バグのステータスを変更すれば、たとえばステータスを「未解決」から「解決済み」に変更すれば、それは自動的に「自分は、そのバグについての見解を変えた」という多くの人へのメッセージになります。そのメッセージには、時間と労力をかけてでも、見解を変えた理由を添えておくべきでしょう(「なぜ解決済みにすべきと考えたのか」など)。そうしておけば、マネージャや顧客をいら立たせることもないし、あとで彼らを説得するため に時間を費やす必要もなくなります。同様に、バグの優先度を変更した場合も、やはりそれは自動的に皆へのメッセージになります。注意すべきなのは、バグの優先度を下げたところで、そのバグを抱えた製品の使用頻度が上がるわけではないということです。

バグレポートを書く際は、1つの欄にあれこれと情報を詰め込みすぎないように注意します。たとえば、「件名」欄に”VITAL :”(vital :致命的) などと書いて、それで、バグの重要度を示す、というようなことを勝手にしない方がいいでしょう。確かに、これでバグレポートがソートしやすくなっていいかもしれませんが、他の人が真似をする時に、微妙に表記を変えてしまうこと(大文字を小文字に変えたり、以後のコロンを抜かすなど)が必ず起きます。別のレポートに記述を流用する際に、”VITAL: “をいちいち削除しなくてはならない可能性もあります。何か情報を追加したい場合には、新たに欄を作った方がいいでしょう。そして、その欄の用途を書いたドキュメントも作っておくのです。そうすれば、他の人が同様の欄を重複して作ってしまうということは防げます。

バグレポートの数が増えてくれば、プロジェクトチームのメンバー全員が必要なレポートを確実に見つけ出せるよう、そのための手段も用意しなくてはなりません。通常は、レポート検索のためのクエリを作ることになります。クエリには、すぐそれとわかる名前をつけ、全員が同じものを使うようにすべきです。クエリに何か変更を加える際は、その度にチーム全員に何をどう変更するのかを通知します。

一つ注意すべきなのは、「バグ数は何かの単位、基準ではない」ということです。コードの行数が労力を示していないのと同じことです。