システムから見たテスト工数の考え方

ある人の日記へのアンサーの整理。

システムが正しく動くためには、テストは不可欠だ。

ところが、どんなにテストをしっかりしたところで、システムの誤りが全て発見出来るわけではない。これは精神論やらマーフィーの法則の類ではなく、理論的に証明されてしまっていることである。だから、

完全なテストは存在しない

ということを前提に考えなければならない。顧客は当然「完全」を求めるが、それは「理論的に不可能」なのだから、妥協点を探さなければならないのだ。

では、どこまでテストをすべきかと言えば、

誤りによる損失 × 発生確率

を求め、これが十分小さくなるまで行うのである。

この「十分小さく」というのは比較の対象が必要なのだが、たいていは、

  • そのシステムの利益
  • テストに要する工数
  • 許容できる損失

などが比較の対象となる。これは、

  • 100円しか儲からないシステムを1000円かけてテストする
  • システム予算が1000円しかないのに500円かけてテストする
  • システムのライフタイム中、最悪10円しか損しないのに100円かけてテストする

ということはナンセンスだという意味にもなる。

正攻法としては、許容できる損失に比較して想定される損失が十分低いというところまで発生確率を下げ、残りは損害保険をかける… というのが良いだろう。そうすれば、「顧客から見れば完全なシステム」と言える。今はシステムに保険をかけることが可能だし。

逆に言えば、そういったことが出来ないようなシステム開発案件は、受注するべきではない。なぜなら、そのシステムを動かすことにより、

  • 開発会社
  • 依頼主
  • エンドユーザ

のいずれかに許容できない被害をもたらすことが予見されるからだ。

もちろん「テストにかけた工数」と「品質」は一致しない。強い相関があるのは確かではあるが、「100円分テストにかけた」ということが、「100円分品質が上がった」ということにはならない。品質は「10円分」しか上がらないこともあるだろうし、「1000円分」上がることもある。そういった力量についての把握をしておかないと、見積りはできない。

# まぁ同じことは開発工数にも言えるが

別の方向で考えるなら、テストのための予算を始めから決めてしまい、その範囲で求める品質が実現できるかということを見積るということも考えられる。そうすれば、過大な見積りにはならないで済む。その「テストのための予算」は、「テストにかける工数」だけではなく、「万一の時の保険の掛金」も含むわけだ。それらがうまくツジツマ合わせられないのであれば、テストの生産性を上げる努力をするか、予算の組み直しが必要になる。

「現実的なシステム」の場合、闇雲に品質を上げることは不経済であり、受益者(開発会社、発注会社、エンドユーザ)にとって好ましいことにはならない。品質の悪いシステムがとんでもないことは確かであるが、過剰品質にしてしまうことも不経済なのである。