テストは欠陥があることは示せるが、欠陥がないことは示せない

≣概要

JSTQBのFoundation Levelのシラバス（以降FLシラバスと略します）の1.3項に「テストの7原則」があります。
JSTQBではテストのシラバス（講義要項、試験範囲や試験の目的・内容など）を公開しています。私は、その中でも私はFLシラバスが一番好きです。シラバスのレベルを超えて「初心者向けのテストの教科書」と呼べるほど包括的に話題を網羅しており、内容がとても良いからです。なかでも、「テストの7原則」はテスト技術者のみならず、プログラマー、プロジェクトマネージャー等々、テストに関心があるすべての人に読んでほしい内容です。
「テストの7原則」は、FLシラバス17～18ページと、分量的には、わずか1ページなので、読むだけなら1分かかりません。
しかし、内容を理解しようとすると、それぞれ、なかなか深いことを語っていますので、もうちょっと時間がかかります。そこで、これから7回に渡りFLシラバス（2018年度版）をもとに、「テストの7原則」をひとつずつ解説していこうと思います。
今回は、原則１「テストは欠陥があることは示せるが、欠陥がないことは示せない」について書きます。

※　みんな大好き「テスターちゃん」でも「テストの7原則　その①～⑨」で9回に渡って「テストの7原則」について連載しています。とても分かりやすくてためになりますので、ご一読されることをお勧めします。

≣ シラバスの記載

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

1.テストは欠陥があることは示せるが、欠陥がないことは示せない

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。

≣ 解説（全体）

Edsger W. Dijkstraは、1969年に執筆した"Notes On Structured Programming" (EWD249)の7ページ目（PDFでは11枚目）に、"Program testing can be used to show the presence of bugs, but never to show their absence!"と書いています。直訳すれば、「プログラムテストはバグの存在を示すために使用することができますが、それらが存在しないことを示すために使用することはできません。」でしょうか。
意訳したら原則1のタイトルそのものですね。ということで、50年以上言われ続けてきている原則です。これってすごくないですか？？

※　ちなみにISTQBのFL Syllabusにおける原則1の英語記述は、“Testing shows the presence of defects, not their absence.”でした。

defectはfault（欠陥）やbug（ちょっと曖昧な言葉。文脈により、欠陥だったり、故障/不具合だったりする）とほぼ同じ意味ですが、faultがfailure（故障）の原因を指し、たとえば、「経年劣化」のようなものも指すのに対して、defect（欠陥）の方は、元々存在する欠陥に限定している点が異なります。ソフトウェアのバグは購入直後の新製品にも存在しますので、ISTQBのFL Syllabusでは、faultではなくdefectという単語が使われています。
（一か所だけ、“defect (fault or bug)”と、defectの説明のためにfaultが出てきますが、他は、faultでもbugでもなくdefectで統一されています。）

≣ 解説（詳細）

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

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。

■　テストにより、欠陥があることは示せるが、欠陥がないことは証明できない

前半のこちらは、Dijkstraの1969年の主張と同じです。一般に「ないことを証明する」ことは困難です。ありとあらゆる原因に対して「ないこと」を確認しないと証明できたことにならないからです。証明することが不可能か非常に困難な事象を「悪魔」にたとえて「悪魔の証明」と呼ばれることもあります。
さて、私たちは「悪魔の証明」に対して無力なのでしょうか？
一つだけ対抗手段があります。それは、証明するときの範囲を限定する方法です。たとえば、「白いカラスはいない」ことを証明するとします。
話を単純にするため、たまに見つかるアルビノ（albino）カラス（メラニンの生合成に関わる遺伝情報の欠損により白い色をしているカラスの個体）を除き、本当に羽根の色が真っ白な種のカラスについて存在しないことを証明することを考えることにします。「そんなカラスは、見たことがない。実際に誰かが捕まえて、いたって分かるまではいないことにしよう」というのが普通の人の考えだと思います。世の中はそれで（「いないことの証明は不要」で）回っています。
ただ、「どうしても証明したい」となったときには上に書いた通り、範囲を限定して証明します。
　・ この机の上に（白いカラス）はいない
　・ 部屋の中にもいない
　・ 建物の中にもいない
　・ 町内にもいない
　・ 県内にもいない
　・ 日本にはいない
　・ 世界中探したがいない
　・ 太陽系にはいない
　・ 銀河系にはいない
「机上→部屋→建物→町内→県内→日本→世界→太陽系→銀河系」と証明するときの範囲を限定しつつ広げていきます。探索範囲を広げるだけでなく、探索する方法を広げてもいいですね。
　・ （白いカラスの）羽根を拾ったことがない
　・ 啼き声を聴いたことがない
　・ 見たことがない
　・ 触ったことがない
などなど。

「白いカラスはいない」ことを完璧に証明できなくても「白いカラスは、この机の上には、いない」は証明できそうです。「求める範囲までいないことが証明できればいいじゃない」という考え方です。
さて、これを「欠陥がない」ことに置き換えて同様に考えてみます。
　・ マニュアルに記載されている動作については欠陥がなくきちんと動く
　・ 仕様書に記載されている個々の機能については欠陥がなくきちんと動く
　・ Google Chrome上では欠陥がなくきちんと動く
　・ リストした因子・水準において、2機能の組合せまでは欠陥がなくきちんと動く
などなど。探索範囲だけではなく、探索する方法についても同様です。「ここまで調べたらいいんじゃないの？」と、証明を求める範囲についての合意が取れれば、実用的にはOKです。
逆に言えば、テストを行うときには、「どういう目的で、どの範囲について、どんな網羅基準でテストしたのか」の情報が大切ということになります。

■　テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない

後半のこちらは、前半の文の言い換えにすぎませんが、最後の「正しさ」というところが気になります。ISTQBの原文では、correctnessとなっています。

Wikipediaによると、

計算機科学における正当性（Correctness）とは、アルゴリズムがその仕様に照らして正しいことを意味する。「機能的」正当性とは、アルゴリズムの入出力動作に関する正当性である（すなわち、各入力に対して正しく出力を生成すること）。

とあります。ISTQBの執筆者がcorrectnessを上記の意味で使ったかどうかはわかりません。想像とはなりますが、原則2が「全数テスト（入力と事前条件の全組み合わせ）は不可能」となっていることや、この項の参照先の文献となっているマイヤーズ本の主張から考えると、「仕様に対するverificationですら証明するにはテストの数が多くなりすぎて不可能」と言っているように思います。

≣ まとめ

いまも、よくわかっていない人は、「今度の商品はバグゼロが必達だ！」といいます。

よくわかっていない人が無視してもよい人なら無視すればよいのですが、無視することが困難な役職が高い人でもいうことがあります。そんなときに、この原則を説明してみるとよいかもしれません。「いいからやれ」と言われる可能性も高いですが。