前回、直交表を用いて81通りのテストケースを9通りに減らしました。なぜそんなことができたのでしょうか。「諦めたこと」と「諦めなかったこと」という観点で整理してみます。
諦めたことは、全ての項目の取り得る値の組み合わせをテストすることです。この方針では、項目数や取り得る値が増えるに従ってテスト数は膨大な数字になってしまいます。
諦めなかったことは、任意の2機能間の組み合わせについて100％のテストを実現することです。つまり、2機能間の網羅率を上げることに注力した戦略を採ったということです。
さて、この戦略は合理的なのでしょうか。バグは2機能間の組み合わせだけで発生するわけではありません。3機能や4機能の組み合わせで発生するケースはもちろんあります。
まずは2機能間の組み合わせに注力する戦略が間違っていない理由を説明していきましょう。表3を見てください。これは、D. Richard Kuhn氏が2004年に発表した論文からの引用です。
表3●D. Richard Kuhnによる（世の中のシステム）の実状
D. Richard Kuhn, Software Fault Interactions and Implications for Software Testing,IEEE Transactions on software engineering, Vol.30, 2004.より
[画像のクリックで拡大表示]
表の横方向はシステムの種類で、エキスパートシステム、OS、組み込みシステムなどを示しています。縦方向のFTFI (failure-triggering fault interaction）とは、バグを顕在化させるために必要となる組み合わせ機能数です。「1」は単機能のテストを意味し、その行の値は単機能テストで顕在化したバグの全体に対する割合を示しています。「2」は2つの機能の組み合わせで発生することを意味し、その行の値は単機能テストと2つの機能の組み合わせで顕在化したバグの割合です。
