≣概要

FLシラバスの「テストの7原則」の2つ目です。前回の原則１は、「テストは欠陥があることは示せるが、欠陥がないことは示せない」でした。原則2は原則1の理由の一つを示している関係（「原則1は成立する。なぜなら原則2があるから」というように“論拠”を示している関係）となっています。

さて、今回の原則2は、「全数テストは不可能」ですが、テストの実務者とテストを良く知らない人のギャップを最も表している原則ではないでしょうか？　「一度でも真面目に全てのテストをやろうとしたらわかる」ので。

原則2は、専門家にとって当たり前でも「テストのことを良く知らない人にとっては当たり前とまでは認識されていない」ため、言い続ける必要がある原則です。

≣ シラバスの記載

『ISTQBテスト技術者資格制度　Foundation Level シラバス 日本語版 Version 2018.J02』の該当部分を引用します。

2.全数テストは不可能

すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。

≣ 解説（全体）

マイヤーズ本に以下の記述があります。

In an ideal world, we would want to test every possible permutation of a program. In most cases, however, this simply is not possible. Even a seemingly simple program can have hundreds or thousands of possible input and output combinations.Creating test cases for all of these possibilities is impractical. Complete testing of a complex application would take too long and require too many human resources to be economically feasible.

2行目の“Even a seemingly simple program can have hundreds or thousands of possible input and output combinations.”あたりですが、「シンプルに見えるプログラムですら百や千の入力の組合せを持てる」とのことです。この文章が原則2の元になったものと思っています。

例えば、ONとOFF状態があるチェックボックスについて考えてみましょう。もし、チェックボックスが2つなら、{OFF×OFF, OFF×ON, ON×OFF, ON×ON}の4つの組合せですが、3つになれば、{OFF×OFF×OFF, OFF×OFF×ON, OFF×ON×OFF, OFF×ON×ON, ON×OFF×OFF, ON×OFF×ON, ON×ON×OFF, ON×ON×ON}の8つの組合せになります。チェックボックスが一つ増えるごとに組合せ数は倍に増えていきますので、10個もあれば、2^10で1,024となります。確かに「チェックボックスが10個のシンプルに見えるプログラムですら1,024パターンの入力の組合せを持つことができる」というわけです

さらに、20個なら2^20で1,048,576ですから100万を超えた組合せとなります。これを全部テストすることを「全数テスト」と呼ぶのであれば、それは非現実的です。仮に、0.1秒間に1回テスト可能な自動テストツールがあれば30時間程度でできますが、出来るからといって、実施する意味はないと思います。

≣ 解説（詳細）

ここからは、FLシラバスの解説をもう少し分解して細かく読み解いていきたいと思います。
まずは、FLシラバスの解説を再掲します。

すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。

■　全数テストは、ごく単純なソフトウェア以外では非現実的

前半のこちらは、Myersの1979年（原則1は“Dijkstraの1969年の主張”でしたので、奇しくもその10年後）の主張と同じです。マイヤーズは入力の組合せ数が指数関数的に増える事実をもって非現実的と指摘しましたが、組合せの他にも、
　・ 入力の値（1から100まで入力できるなら100回？　アナログ値は？）
　・ ループ（プログラムにループがあったら無限大？）
　・ 状態遷移（ループがあったら全パスは無限大？）
　・ タイミング（1秒間に何回実施する？）
　・ ロングラン（何日間連続稼働させる？）
等々についても、全部の確認はできません。

■　全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである

後半のこちらは、FLシラバスからの提案となっています。
JSTQBのテスト戦略（アプローチ）は、リスクベースドテストですから、一番目に「リスク分析」を挙げているものと思われます。

例えば、家を建てたら、まずは、トイレが流れること、風呂が沸くことなどなど生活が成り立つかのテストをしますよね。続いて、防音・防火・耐震など、不備があったら困ることを（リスクが高い順に）確認すると思います。「お風呂の蓋の色が注文と違う」といったような、問題があったとしても軽微な問題だったり、直ぐになおせることが期待できるのであれば、その確認は後回しにすることでしょう。それが、リスクベースドテストです。

次に「テスト技法」についてですが、上の例に当てはめていえば、
　・ 入力の値：　同値分割法、境界値分析
　・ ループ：　0回、1回、2回、MAX回
　・ 状態遷移：　状態遷移図・表、N-スイッチテスト
　・ タイミング：　並行処理テスト
　・ ロングラン：　統計技法、シナリオテスト技法
　・ 組合せ：　直交表やペアワイズなどの組合せテスト技法
などが対応するように思います。

最後に「優先度」ですが、こちらは「テスト条件」、「テストケース」、「テスト手順」などの優先度をつけることを意味します。優先度はリスクという発生してほしくないネガティブな予測からもつけますが、「ビジネスを成功させるため」といったポジティブな（実現してほしい）ことについての優先度も考慮します。

≣ まとめ

SWEBOKのテストの定義は、

期待されるビヘイビアを求めて、通常は無限に大きいと考えられる実行ドメインから適正に選定された有限のテストケース集合を用いて、プログラムビヘイビアの動的検証を行うことである。

 となっています。全数テストが不可能だから有限のテストケースを適正に選択するのですね。