梅田さんの品質管理に関する記事(http://www.thinkit.co.jp/cert/project/1/5/4.htm)の中に次の記述があります。

テスト工程においてバグがでないのは、品質が本当に良いのか、テストのやり方が悪いのかのどちらかです。

この見極めができずに苦慮することがしばしばです。記事は次のように続きます。

それを見極める1つの手段がバグ曲線です。テストの際に報告される障害の数を管理し、それをグラフにプロットするのです。一般に、1日当たりの障害発生数はテストの初期段階から急激に増えて行き、ピークを迎えてから徐々に少なくなっていきます。その曲線をプロットして、発生数が十分小さくなった段階で品質が良くなったと認識するのです。障害が最初から少なく、ピークを迎えない場合は、テスト方法やテスト者の技量不足が考えられます。

目新しい意見ではありません。きわめて教科書的な正統派の答えです。

しかし、この答えにあまり納得はしていません。最初から障害報告数が少ない場合、テストのやり方の問題と判定する部分には異論がありません。品質の良い場合を誤判定してテストのやり方の問題とする可能性はありますが、この誤判定はそれほど深刻ではありません。

問題は、障害報告数が徐々に少なくなれば品質が良くなった、と判断する部分です。最初に障害報告数が多ければテスト方法には問題がないので、そのテストの方法で障害報告数が減少すれば、品質が上がったと判断するという論理です。障害報告数を決める因子として、品質とテスト方法が支配的、という前提を受け入れるなら、何の異論も無いように見えます。

ここに致命的な見落としがあります。テストをする人間が疲れてくる、という因子です。疲れるという言い方に語弊があるなら、慣れてくる、と言ってもいいです。

つまり、元は、障害報告数が品質とテスト方法の関数で、テスト方法は時間に対して定数、品質が時間の関数と仮定しています。このため、時間とともに障害報告数の変動を見れば、品質の変動が分かるという論理です。テスト方法も実は時間の関数だと仮定すると、この論理はなりたたなくなります。

経験的に、テスターが疲れて行く現場を見ています。こうなると、障害報告数が減少しても、品質が上がっているのか、疲れてテストが雑になっているのか区別がつきません。区別がつかないどころか、後者の確率の方が高いような気すらします。この問題に対して、「ソフトウェアテスト293の鉄則」(http://dev.ariel-networks.com/Members/inoue/software-testing)では、「鉄則283:多様性ほどほどの原則」を挙げています。テスターがテストに慣れすぎることを防ぐために、テスターの作業を交換したりテスト方法を変えるべき、という意見です。これはまあまあ有効に機能しますが、交代であっても、ずっとテストをしていれば人間疲れるのは変わりません。

テストにかける人数が多いほど、かける時間が長いほど、ソフトウェアの品質が上がると考えるのが常識的な考えです。10人のテスターがいて、テスト期間が1ヵ月あれば、10人に1ヵ月目一杯テストしてもらおうと考えるはずです。

テスターの疲労を考慮すると、次のようなテスト戦略の方が品質は上がるかもしれません。10人を5人ずつのふたつのチームに分けて、最初の半月、半分の5人のみにテストをさせて、残りの5人は南の島で遊ばせておきます。半月後、南の島から5人を呼び戻してテストに参加させます。最初の5人を南の島に送っても良いですが、新たにテストを始めた人が未知の障害報告を挙げれば刺激になって気力が戻るかもしれないので、最初の5人も残したままにします。新しい5人が参加して、一人当りの障害報告数が有意に増えるようなら品質に問題があると言えそうです。逆に、人数が増えても障害報告数が有意に増えない場合、品質は良いと判断できそうです。単純計算では、5人x半月のテスト工数が減りますが、これぐらい挽回できそうな気もします。人的余力のある開発チームで是非試してもらいたいものです。