バグを求めるものたち　後編

テスト工程の品質を、テスト項目数やバグ件数のような「量的」な指標だけで把握することには限界がある。

プログラムの規模などから、どのくらいのテスト項目数が必要なのか、どのくらいバグが発見されるのか、といったことは、ある程度は想定できるかもしれない。

しかし、そうした量的な指標が有効なのは、開発するシステムの種類や特徴、プロジェクトチームのスキルなどが、安定している場合だけであろう。例えば、同じ開発メンバーが同じようなシステムを作る場合には、有効かもしれない。

逆に言えば、どんなプロジェクトにでも通用するような、量的基準を作ることは難しい。例えば、テスト項目数が基準値を満たしていても、テスト観点に抜け漏れがあれば、何の意味もない。

★
当たり前の話ではあるが、テスト工程の「品質」を正しく把握するためには「質的な」評価が必要である。

テストを行うに際に大切なのは、テスト項目の数ではない。テストの観点に偏りや抜け漏れがないか、ということである。それを確認するためには、テスト項目の内容を詳細にチェックしなければならない。

また、発生したバグについても、ただ件数を数えるだけではなく、内容まで分析しなければ意味がない。例えば、結合テストで10件のバグが見つかったとしよう。数字だけしか見なければ、ただそれだけの話である。しかし、内容まで調べれば、そのうち９件が「単体テストで見つけておくべきバグ」であることが分かったりする。このように、質的に意味のあるレベルまで分析しなければ、数値の意味はない。

★
量的な評価が、テスト項目の数を数えるだけでできるのに対し、質的な評価をするには、非常に多くの手間が掛かる。

しかし、だからといって、量的な指標を絶対視し、それだけでテストの品質を決めつけてよいというものではない。

管理者が恐れるべきは、「管理しているつもりになること」である。数値を測定し、表やグラフを作れば、なんとなく管理をしている気分になってしまう。しかし、質的に意味のない数値は、いくら集めても役に立たない。

そうした実のない管理方法が最悪の結果として現れるのは、抗いがたい権力をもって、開発者に「量的なノルマ」を課した時である。

前編、中編に書いたような弊害は、その例である。

ここで、「バグが出ないこと」に悩まされていたプロジェクトマネージャは、顧客に虚偽のバグ数を報告をすることもできたはずだ。それをさせなかったのは、彼の人としてのモラルである。

しかし、この顧客が必要以上に「バグ数の要求」を続けるならば、いつか誰かが虚偽の報告をしないともかぎらない。

バグ数を増やすために故意に品質を下げるくらいなら、嘘をついたほうがマシだと考える開発者は必ずいる。

開発者にとって、「品質を上げる」ということは、それほど重要なものなのである。