組み合わせテストを現場で使うときの判断指針とPDCA：現場で使うためのオールペア法、直交表の基本（4）（1/3 ページ）

組み合わせテスト実施時の判断のコツは分かったけれど、どのくらいの「強さ」で、どの手法を組み合わせればいい？ 筆者の経験から、判断基準やテストのPDCAにおける「トレードオフ」の正しい悩み方、賢い対策の考え方を紹介します。

[五味弘，OKI（沖電気工業）]

連載バックナンバー

　本連載では、組み合わせテストを科学的かつ効率的に実施するための方法として「オールペア法」「直交表」を紹介しています。第一回では、代表的なテスト手法とその課題を整理し、第二回では「オールペア法」「直交表」がどういったものかを、ツールを使って「とにかくやってみる」ことで理解できるように配慮して紹介しました。その中で、オールペア法や直交表を使えば「理屈の上では」6561件の組み合わせテストを15件にまで削減できることを示しました。しかし、それだけでは開発現場の実務には不十分な場合が多く、第三回で紹介したように、やはり実際のプロジェクトで使いこなすためには勘や経験から得られるコツも重要です。

　本連載で紹介してきたオールペア法や直交表は、組み合わせの「強さ」（＝品質の水準）を保証することがポイントです。これらは勘と経験に頼った職人技の組み合わせテストではないことを保証するものなので、間違えないようにしましょう。

　なお本連載では、テストケースの組み合わせについて「強さ」「因子」「水準」といった独特の単語が出現しますが、これらについては連載第二回で意味を解説した通り、「オールペア法」「直交表」に特有の概念です。独自の用語で“迷子”になりそうになったら、連載第二回に立ち返ってみてください。

　今回は前回（第三回）に引き続き、実際の開発現場でオールペア法や直交表を使う際のコツや考え方のヒントを紹介します。中でも、本稿では「組み合わせの強さをいくつにするのか」「組み合わせテストの手法をどのように選定するのか」といった要素の選定方法や考え方を見ていきます。

組み合わせの強さを幾つにするのかを考えるヒント

　「組み合わせの個数（「強さ」）をいくつにするか」という網羅基準の選定はいつも判断が難しい問題です。

「強さn」でバグ発見率が飽和する

　ここで、「組み合わせテストにおける欠陥数」を統計的に調査した論文を見てみましょう。図1は、各プログラムに応じて、欠陥が何個の因子の組み合わせで発見できるかを調査したものです。

図1　強さによる積算欠陥発見率の遷移（D.Richard Kuhn, etc: Software Fault Interractions and implications for Software Testing, IEEE　Trans. on Software Engineering, vol.30, No.6,June 2004よりデータを引用して筆者がグラフを作成）

　図1の横軸が因子の組み合わせ個数を示しています。これを参考にすると、どのくらいの強さであれば欠陥の積算発見率が飽和せずに一定まで上昇していくかが分かります。

　飽和した状態ではコストを掛けて強さを大きくした組み合わせテストを実施しても、欠陥の発見率はあまり向上しませんから、無駄なコストを掛けることになります。

　図1から、「強さ1」では全てのプログラムにおいてテストは不十分であることが分かります。2個以上の強さの組み合わせテストが必要なことが分かりましたが、「強さ2」でもプログラムによってはバグの発見率は50％から80％までと低いものがあります。一方で、「強さ2」で90％以上の欠陥が発見され、それ以上強くしてもほぼ飽和しているものもあることが分かります。

　第一回でも言及した通り、テストはコストと効果のトレードオフで実施するものです。組み合わせテストでは、「強さ」を大きくするほどコストは増大しますので、「要求される品質に見合うコスト」で「強さ」を選定する必要があります。例えば、「重要なプロダクト／プロジェクトであれば、『強さ』を一つ加算する」という考えもあります。

バグ発見率から見て、強さ2は必須、そこから先は……

　図1はプログラム種別（POSIXモジュールやサーバーなど）によるグラフですが、ユーザー種別により強さを変えることも考えられます。実際、情報処理推進機構（IPA/SEC）の『ソフトウエア開発データ白書 2014-2015』によれば*、業種によってテストケース数に有意な差があることが分かります。さらに個々のプロダクト、プロジェクト、ユーザー、要求、納期、費用などによっても、選定基準は変わってくるでしょう。また「強さ」や手法を決定するためにも、過去の資産の情報として計測することは必要になります。

* 情報処理推進機構（IPA/SEC）『ソフトウエア開発データ白書 2014-2015』p.196, pp.208-209）

　やや乱暴に「強さ」の選定方法をまとめると、「強さ1」と「強さ2」では図1で分かるように明らかな差がありますから、「強さ2」は必要です。逆に「強さ2」と「強さ3」では、プログラム種別によって効果に差があるものとないものがありますから、要件に応じて検討しなければなりません。

コストから逆算して「強さ」のガイドラインを作る方法

　「強さ」をどう設定するかについては、コストから考えることもできます。「強さ2」と「強さ3」で、それぞれテストケースを生成してみて、テストケース数がコスト的に可能であれば、「強さ3」を選択すればよいでしょう。それが微妙なときはやはり上記のように「強さ2」か「強さ3」を、状況に応じて選択するようにします。

　実際の開発現場では、組織全体でプログラム種別やユーザー種別などで層別して、「強さ」や手法の選定ガイドラインを作成します。例えば「三階層システムでは『強さ3』にする」などのガイドラインを作成しておきます。

　このガイドラインをベースにして、個々のプロジェクトで状態に応じて、最終的に「強さ」や手法を選定していくのです。もちろん、「組織全体のガイドラインと個々のプロジェクトの選定の綱引きをどこにするか」というのも、テストの重要な運用の一つです。