それだけの数の不具合（バグ）がみつからないということは、テストが十分でないのだ、というわけである。
確かに、テストという工程だけをみれば、そのような判断も正しいのかもしれない。しかし、システム開発全体としてみれば、弊害もある。
伝統的なシステム開発では、テストの工程はプログラミングの工程の後に行われる。つまり、その場合、プログラミングが完了した時点で、一定数以上のバグが残っていなければならないということになってしまうのだ。
プログラミング完了時点でのバグをゼロにすることは、プログラマの目標のひとつである。彼らは、その目標を目指し、工夫、努力を続けている。前編 で述べたような「動作確認」もそのひとつである。
このようなプログラマの努力によって、プログラミング工程での品質が上がれば、テスト工程で見つかるバグは少なくなるのは当然である。
しかし、そのような場合でも、発見されたバグの数だけで、テストの精度が評価されるような状況では、「テストが十分に行われていない」と判断されてしまうのである。
前編で登場したプロジェクトマネージャの「プログラミング中にプログラムを動かすな」という指示は、こうした背景から出てきたものであった。彼は、顧客から、テスト工程の完了条件として、「最低バグ数」を提示されていたのである。
彼は過去にこの「最低バグ数」をなかなかクリアできずに困ったことがあるという。今回も、テスト工程でのバグが少なくなってしまうことを心配し、そのような指示を出したのである。
彼は、「動作確認」をプログラミング工程で行うか、テスト工程で行うか、という違いを、それほど重要視していないのかもしれない。
確かに、テスト工程で抜け漏れのない 100% 完璧なテストを行えるのであれば、彼のようなやり方でも、最終的に完成したプログラムの品質が下がることはないだろう。
しかし、現実には、よほど単純なシステムでない限り、「完璧なテスト」を行うことは困難である。「プログラミング中の動作確認」を禁止すれば、当然、バグが見逃される可能性は高くなり、品質は下がるだろう。実際、プログラミング中でなければ気がつかないような「テスト観点」というのもある。
また、仮に「完璧なテスト」が行えるとしても、バグというものは見つかるのが早ければ早いほどよいものである。後の工程になるほど、バグを修正することよる影響範囲が広くなるし、本来は必要なかったはずの「再テスト」の手間も増えるからだ。
プログラミング中にバグを見つけられるチャンスがあるのに、それをわざわざ禁止して手間を増やし、更には品質を下げてしまうというようなやり方が、果たして正しいといえるだろうか？
続く
■関連記事
・バグを求めるものたち 前編
・バグを求めるものたち 後編
若手SEのための ソフトウェアテストの常識
posted with amazlet
on 06.05.06
秋本 芳伸 岡田 泰子
ディー・アート (2006/01/25)
ディー・アート (2006/01/25)
プロジェクト品質マネジメント―全体最適を実現する4つの柱
posted with amazlet
on 06.05.06
ティモシー・J. クロッペンボルグ ジョーゼフ・A. ペトリック
生産性出版 (2003/08)
売り上げランキング: 65,349
生産性出版 (2003/08)
売り上げランキング: 65,349