テスト項目を増やせば増やすほどバグは増えます。
バグには露見したバグと、潜在バグがあります。
潜在バグの量については２つの異なる考え方があります。
- バグを取っても取っても沸いてくるという考え方
- 総量は決まっているという考え方
石油(原油)の埋蔵量と似ています。
埋蔵量を年間採掘量で割ったものが採掘可能年数として毎年発表されています。４０年くらいといわれて、私が子供の頃から数えても数十年は経ちます。
埋蔵量が増えているからです。
埋蔵量の増加は頭打ち気味といわれているため、グラフで見ればいずれ飽和すると考えることができます。物理的に存在する量と、採掘技術の進歩の速度、コストと価格の天秤で、取れる総量は決まっているということです。それを究極埋蔵量などと呼んだりします。２１世紀になってすぐ、この究極埋蔵量が倍増する出来事がありました。
さて、バグの話に戻ります。
コストをいくらかけてもよいのなら、バグはいくらでも摘出できるということは前にも書きました。たぶんそれは正しいのです。バグの定義にもよりますが、到達不可能なコード、例えば呼び出し元がコメントアウトされ、どこからも呼び出されない関数の定義や、誰も値を変更しないし参照もしないローカル変数の定義など、１０００行当り１００個くらいのバグは簡単に摘出できます。
仕様の通りに動きさえすればよいというような甘い品質基準では、そのような「コーディング上の不ぞろい」程度の問題に比例して深刻なバグが多数潜在しています。
テスト目標における１０００行当り５件のバグ摘出、などというものは潜在バグ総量の経験則に基づいているようです。
同じ製品ドメイン、同じ組織で繰り返しおこなわれれる実装作業では潜在バグの作りこみと製品規模に相関関係があるだろうというわけです。
しかし所詮は見積もりです。１０万行のプログラムに５００件のバグが潜在していると考えたとき、５００件のバグを摘出したからといってもうそれ以上バグはないとは言い切れません。本当の潜在バグ数は誰にも分からないからです。
リリースされる製品に含まれる潜在バグをゼロ個に近づけるにはいくつかアプローチがあると思います。
- バグが摘出できなくなるまで摘出(テスト)を繰り返す
- 潜在バグ個数を見積もって、摘出(テスト)を計画する
前者では計画は立ちません。計画的におこなうなら選択の余地はないのです。
未知ドメインにおける新組織ならどうでしょうか。見積もりの精度はかなり悪くなります。
そうかといって、
- 予算の範囲内で可能な摘出(テスト)のみをおこなう
では、数百個の潜在バグが取り残されて大クレームとなるかもしれません。
見積もりの精度がよくても工数コストをみっちり絞られたら同じことです。
低いコストと工数で効率よくテストをおこなえなければ、いくら良い製品でもろくでもない結果が待っているということです。
コメント