37-バグレポートの使い方

「プログラマが知るべき97のこと」の37個目のエピソードは、バグレポートに関する話です。非常に悲しいことですが、効果的なバグレポートを書くことのできる人は多くありません。それがソフトウェア開発に関して無知なユーザであるならば仕方のないことかもしれませんが、ソフトウェア開発に従事しているーさらに言えばプログラマと呼ばれる職業の人でもバグレポートを書く事ができません。これは学ぶ機会が乏しいというのもあるかと思います。

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

バグレポートの書き方として、このように書かれていますが、何か気付くところはないでしょうか？ここで「これってユニットテストの書き方と同じでは？」と気付いた人はユニットテストについて普段から実践しているプログラマであると思います。
一般的にユニットテストは次のようなフォーマットで記述されます。

@Test
public void テストの内容() throws Exception {
  // 1.テスト対象のクラスの準備
  Something target = ...
  // 2.期待される結果
  Result expected = ...
  // 3.実行
  Result actual = target.doSomethin();
  // 4.検証
  assertThat(actual, is(expected));
}

バグの全てがユニットテストで記述できるとは限りません*1が、基本的には再現方法と本来の仕様、実際の動作という要素は変わりません。もし、バグレポートが不完全でこれらの要素がかけていたり、それぞれが不十分であったならば、開発者はユニットテストを記述することができません。現実としてはある程度は予想したり開発者で再現させた上で行うと思いますが、開発者に負担がかかります。そもそも再現方法すら書いていないならば、確認しようがないのです。
したがって、開発者側からしたならばバグレポートが効果的に書かれている事は非常に助かることです。もし、再現するためのユニットテストのコードがバグレポートに添付してあるならば完璧です。後はユニットテストに組み込み、グリーンにするだけで済むのですから。バグレポートは開発者を手助けするものであり、不快にさせるものではありません。ですが、バグレポート次第ではただのクレームでしょう。
また、バグを定量化することについて次のようにも書かれています。

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

コードの行数についてはまさにその通りです。しかし、自分としてはある程度はバグの数はソフトウェアの健康度合いを図るバロメータであると思います。勿論、それが絶対基準のようになっているケース*2については違和感を感じます。どこまでという基準は定義しにくいですが、バグだらけよりもバグが少ない方がいいですよね。

プログラマが知るべき97のこと

*1:表示上の不具合などは出来るかもしれないがコストがかかりすぎる

*2:コードｘステップに付きｘ件のバグがあるはずであり、検出できないならばテストが不完全であるなど