組み合わせテストは、「組み合わせ爆発」という言葉がある通り、テストケースの規模が大きくなりがちです。それに付随して、開発のスピードやコスト、必要リソースに悪影響を及ぼすこともあります。
そのため、組み合わせテストの組み合わせ削減は、テストケースの削減、そしてそれに伴うリソースや期間の削減に貢献しやすい領域です。
今回は、その組み合わせテストの組み合わせを削減するアプローチについて解説します。
組み合わせテストの組み合わせを削減するアプローチ
パラメータと値を削減する。組み合わせを実現不能にする
パラメータ（因子）を減らしたり、パラメータが取りえる値（水準）を減らしたりすると、テストすべき組み合わせの数を直接減らせます。
このパラメータや値の削減手段として、最もインパクトあるのが、機能や設定、構成仕様の削除です。価値がない、使われていない、ビジネスが成り立たないような機能・設定・対応環境を削除することで、パラメータや値を根本から削除できます。
なお、この手段はユーザやビジネスへの影響が大きく、単なるテストの効率化目的では推進困難です。現実的には、ビジネス観点での削除判断に、組み合わせテスト効率化がのっかるアプローチが取られます。ただし、組み合わせテストの変動は、ビジネス上の判断する上でどれぐらい品質保証が楽になるかの判断材料になります。
次に、パラメータや値の組み合わせを実現不能にする実装で、組み合わせ数を削減できます。
まず外部からの入力に対しては、入力の制限や、入力バリデーションといった防御プログラミングの推進で、取りえるパラメータや値、組み合わせを削減できます。例えば簡単な例ですが、文字入力ならば、テキストボックスの設定で入力できる文字数や文字種を縛ることで、値のパターンを削減できます。さらに画面を分けて同時入力を不能にする、特定の選択で入力項目をグレーアウトして操作不能にするといったもので、組み合わせを実現不能にできます。
またある程度制御できる内部インターフェースからの入力については、契約による設計の推進が有効です。適切な事前条件を具体化して遵守することで、事前条件を満たさない組み合わせを組み合わせテストから排除できます。さらに、アーキテクチャ上の境界の結合性を低く設定することでも、パラメータや値の削減に貢献します。具体的には、簡単なものならグローバルスコープの変数削減や無駄な引数の削除、複雑なものなら並行処理の保護（並行処理は結合性の悪化を通して組み合わせを複雑化させがちです）や、入出力の抽象化・カプセル化といったものがあります。
なお、留意事項として、組み合わせを実現不能にして組み合わせテストを減らすアプローチでは、組み合わせが実際に実現不能であることを確認・保証する活動が求められます（HAYST法でいう禁則のテスト）。前述のテキストボックスの例では、単機能テストで入力不能なことを確認する必要があります。契約による設計の推進では、Assertionによる事前条件確認やコードレビューなどが必要になります。
組み合わせに起因するプロダクトリスクを下げる
パラメータと値の削減、実現可能な組み合わせの削減に次ぐ有効策が、組み合わせについてのプロダクトリスクの削減です。というのも、求められるテスト網羅基準の厳しさはプロダクトリスクと連動するためです。プロダクトリスクを削減できれば、組み合わせの網羅基準の緩和につながります。
組み合わせのプロダクトリスクを下げるアプローチの一つは、パラメータ間の結合性を下げ、特に関係のないパラメータは明確に結合を分離する、結合性の設計・実装の工夫の推進です。このアプローチはプロダクトリスク事象の発生可能性の削減に貢献します。
その中でも、プロダクトリスクの高い機能やコンポーネントを、他のものから結合度低く分離する設計アプローチが有効です。例えば認証、プライバシー、課金などトラブル時の損害に紐づくようなハイリスクなコンポーネントは、アーキテクチャ上でリスクの漏出を防止するバウンダリを設けて結合を分けると、それ以外のローリスクなコンポーネントとの組み合わせのプロダクトリスクを削減できます。
次に、プロダクトリスクの源を置換・除去するアプローチも、一部の高信頼性開発で有効です。例えばプロダクト中の有毒成分（例えば製造装置の触媒など）を毒性の低いものに入れ替える、高出力装備（例えば放射線射出装置など）の出力を低いものに変える、といったものです。これは、組み合わせを含めた、プロダクトリスク事象の影響度の削減に貢献します。
上記の対策をまとめると「組み合わせに関わるプロダクトリスクを局在化し、リスクレベルを下げる」のが組み合わせテストの削減に有効なアプローチになります。
組み合わせテストが得意な他活動にテストの責務を渡す
QA活動・テスト活動の中には、特定の組み合わせテストを効率的にこなせるものがあります。例えば自動テストは、入力条件を変えながら同じ機能実行を何度も繰り返すテストが得意であり、それに当てはめられる組み合わせテストを効率よくこなせます。
ですので、そうした組み合わせテストが得意なQA・テスト活動を導入して、テストの責務を渡してしまえば、自分たちの組み合わせテストのテストケースを削減できます。
例えばカメラの顔認識AFのようなアルゴリズムは、膨大な組み合わせ条件を持ちます。そのような場合でよく取られるのが、次の２つのテストで膨大な組み合わせテストを効率的に対処する方針です：
そしてアルゴリズムの膨大な組み合わせテストの責務を上記の2つの自動テストに移動させる形で、実機を使ったシステムテストの組み合わせテストを削減します。
詳細なテストが必要な個所はピンポイントのテストを充実させ、全体の一律網羅を緩和する
プロダクトリスクは、機能やコンポーネントによってプロダクトリスクに濃淡があります。
例えば一般的なサービスでも、ビジネスの成否を左右する重要機能や、バグが発生した時の損害の大きい機能はプロダクトリスクが高く、それ以外の補助的な機能はプロダクトリスクが低いです。
また組み合わせの仕様についてもプロダクトリスクに濃淡があります。結合性が強いパラメータのセットは、組み合わせに起因するプロダクトリスクが高く、結合性が低いパラメータのセットは、組み合わせのプロダクトリスクが低い傾向があります。
そのため、特に詳細なテストが必要な箇所については、ピンポイントでテストを充実させると、他の箇所の組み合わせテストの網羅基準を緩和できます。例えば次のようなアプローチです：
●ピンポイントと一律網羅のテスト設計技法の組み合わせ
結合性が高いパラメータの組み合わせについては、デシジョンテーブルテスト等を使って詳細な網羅を行い、結合性が低い組み合わせについては、シングルワイズテストやペアワイズテストで組み合わせを減らしたり、組み合わせをテストしなかったりするアプローチです。これにより後者の組み合わせの網羅基準を緩和しやすくなります。
●複数の抽象度や網羅基準の組み合わせ
例えば、リスクが高い機能については、詳細なパラメータ・値で組み合わせテストを設計し、リスクが低い機能については、抽象化したパラメータや値（例えば値をグルーピングしてまとめる。これにはクラシフィケーションツリー法が有効です）でテスト設計するアプローチです。これにより後者の組み合わせテストのテストケースを削減できます。
注意：効果的な組み合わせテストの削減には、組み合わせ起因のプロダクトリスクの削減が不可欠
前述のアプローチの多くでは「ピンポイントのテストの拡充で組み合わせテストを削減」「他のテストにテストの責務をまわして自分たちのテストを削減」のような、テストの役割分担で組み合わせテストを改善するものがありました。
注意として、このような役割分担の工夫による組み合わせテスト削減は、組み合わせに起因するプロダクトリスクをマネジメントし、改善してこそ推進できます。
例えば、ソフトウェア開発においては、BOF等のメモリバグ、デッドロックといった並行処理バグ、リソース占有といった、結合性の設計の工夫を根本から破壊するバグがあります。こうしたバグがありふれていると、パラメータ間の結合性が弱い・強いの判断は困難になります。例えばフロントエンドの描画のコーディングミスで、構造的に分離されている重要コンポーネントの動作が異常になるといったことも起こりえます。そうした状況では「他でテストするので、フロントエンドのテストは削減してよい」みたいな判断が難しくなります。
こうしたものに対策し、「組み合わせに関わるプロダクトリスクを局在化し、リスクレベルを下げる」アプローチを推進することが、テスト設計の改善につながります。
