36号：テストとは？

≣ 概要

「テストとは何か？」ここでは、偉大な2人の先人（先人と言っても、Myersは1946年12月生まれであり、ご存命です）の言葉を味わい、さらに、ソフトウェア工学の定義と読み比べることによってテストとは何かについて考えていきます。
テストの定義に正解があるわけではありません（と思っています）。時代や使用する技術によって変わりますし、同じ時代でさえコンテクストによってテストについての考え方や定義は変わると考えています。

ただし、変わるとは言っても、先人たちが考えたことを【踏まえて】議論を重ねて、「より良い方向に変わっていく」ことが大切と思います。

≣ Edsger Wybe Dijkstraの示唆

ダイクストラ(1930/5/11 – 2002/8/6)は、7人目のチューリング賞受賞者（1972年に受賞）です。
前年の6人目の受賞者は、「人工知能; Artificial Intelligence」という用語を作った人工知能の草分け的研究者のJohn McCarthyで、再来年の9人目は数学者であり、計算機科学者であり、さらには、TeXの開発者でもあるKnuthです。ダイクストラは、そういう時代の人です。
ダイクストラは、また、構造化プログラミングの提唱者として有名です。「GOTO文は有害である」とした、“Go To Statement Considered Harmful”の論文でも有名ですね。
なお、EdsgerとEdgarのどちらのスペルが正しいかについては分かりませんでした。論文にはEdsgerとありましたので、ここでは、Edsgerとします。

ちなみに、書籍でもEdgarの綴りが採用されているものもあります。ダイクストラはオランダ人だから本当はEdsgerで、英語表記だとEdgarとなるのでしょうか。なお、世界初の推理小説と言われる「モルグ街の殺人」を執筆した、アメリカ人のエドガー・アラン・ポー（推理小説家である江戸川 乱歩のペンネームの由来となる小説家）は、“Edgar Allan Poe”です。

さらに話は少々脱線しますが、岸田孝一さんとダイクストラの次のやり取りが好きです。（岸田さんは1936年生まれなのでダイクストラよりも若干若い。）

閑話休題、ダイクストラのテストに対する次の示唆が今回のポイントの一つです。

Program testing can be used to show the presence of bugs, but never to show their absence!
「テストでプログラム中の欠陥の存在は示せても、欠陥が存在しないということは示しえない。」 （1969年）

こちらは「テストの7原則」の“原則1”の元ネタということで、以前、このブログでも取り上げました。

たとえ、そうであったとしても、テスト以上に効果的で、かつ、効率的に欠陥を見つける方法は見つかっていませんし、どんなに優秀な開発者だってミスをして欠陥を作ってしまうことがある以上、テストを止めるわけにはいきません。

プログラミング力を磨くとか、フォーマルメソッドを使うとか、良いレビューをするという方法もあります。そちらの方が効果的かつ効率的かもしれません。けど、それって半世紀以上前から言われているのですよね。

なお、個人的には、「プログラム中に欠陥が存在しないということは示せない」としても、「（テストを実施することで）リリース後、その商品やサービスが使われなくなるまで、バグがユーザー先で見つかることはない」という命題なら果たせそうな気がしていますし、それを常に実現できるように日々精進しています。「使われなくなるまで」は曖昧なので、例えば「（リリース後）3年間は」に言い変えたらどうでしょう？　グッっと実現可能性がある気がしませんか？
Knuth reward checksのように、決して簡単なことではありませんが。

≣ Glenford James Myersの定義

「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 （1979年）

マイヤーズ（1946/12/12 - ）はIBMのエンジニアでした。たくさんの領域で本を執筆されています。品質関係の技術者は、まずは、『ソフトウェア・テストの技法』と、『ソフトウェアの信頼性』の2冊を読んでおきましょう。

「たくさんの領域で本を執筆」と書いた通り、一つのことを深く研究するというよりは、IBMの難しい研究成果を平易な言葉で分かりやすく伝える才能が卓越している人のようです。名著と呼ばれている『ソフトウェアの複合/構造化設計』もマイヤーズが執筆した本です。

そんなマイヤーズがテストのコツを「エラーを見つけるつもりで実行する」と述べているところが私は好きですし、「本当にそうだなあ」と思います。

「この辺に、まだ、バグがあるはずだ」と信じて、それを見つけるつもりで操作するのと、ただ漠然とテスト手順書に書かれたとおりに操作して期待結果を確認するのとでは、結果（見つかるバグの数や質が）全然違うと思うからです。
開発者本人がいくらテストしても見つからないバグをテスト担当者が10分も触るとみつけてしまうのは、そういう心理的な面が大きいと思っています。

≣ SWEBOK（2004）

「ソフトウェアテスティングは、プログラムが、日常生まれる無限の実行ドメインから適切に選択された（selected）テストケースの有限（finite）集合のうえで行われる、期待される（expected）振る舞いを提示するための動的（dynamic）検証から構成される。」（2014）

SWEBOKは“Software Engineering Body of Knowledge”のことです。日本語では、『ソフトウェアエンジニアリング基礎知識体系』と訳され書籍化されています。
ソフトウェアテストは要求、設計、構築に続き、SWEBOKの第4章に位置付けられています。要は、ソフトウェアテストはソフトウェア工学の大きな要素の一つということです。

SWEBOKの定義では「期待される振る舞いを提示するための動的検証」となっていることに注意してください。振る舞いなので、構造のテストではないですし、動的検証なのでレビューは含みません。

≣ まとめ

今回は、「ASTERセミナー標準テキスト」の8ページについてでした。実は、9ページと10ページも「テストとは？（続き）」なのですが、そちらはそちらで、今現在のテストにどう取り組めばよいかという大切な話なので、このnoteでも分けて書くことにします。