【ソフトウェアテストの７原則】悩み多きテストに役立つ大事な指針

ソフトウェアテスト。設計通りにソフトウェアが機能しているかを確認する、大事なプロセスです。

一方、テストでなにをどこまでやればよいの？判断にとても悩むプロセスでもあります。

そんなテストへの指針を示すのが、「ソフトウェアテストの７原則」です。

ソフトウェアテストの７原則とは

ソフトウェアテストの７原則（7 Principles of Software Testing）とは、ISTQB（国際ソフトウェアテスト資格認定委員会）によって収集および確立されてきた原則です。テストの核心として認識されています。

順番に見ていきましょう。

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

『テストしてエラーが出る。だから、そのソフトウェアにはバグがある』…これはもう明確な事実です。

では、『テストしてエラーが１つも出ない。だから、そのソフトウェアにはバグがない』…とはなりません。

何万件のテストを重ねたとしても、まだやっていない他のテストをすればエラーになる、その可能性は無くなりません。ソフトウェアにバグがないことの証明は「悪魔の証明」と同じです。

「悪魔は存在しない」ことの証明は、「存在する」という全ての可能性を否定しなければならない。それは現実的に不可能である。

ソフトウェアにバグがないことを証明するのは、不可能なのです。これがソフトウェアテストで認識すべき、重要な大前提になります。

クライアントとの契約の際も、「バグがないこと」を完成条件に定義してはいけません。できるのは「決められたテストを全てクリアする」と定めるところまでなのです。

ソフトウェアに欠陥がないことは証明不可能。これを大前提にすること。

全数テストは不可能

全数テストとは、「ありとあらゆる条件をすべて網羅したテスト」です。

ソフトウェアとは、突き詰めれば、インプットに対してアウトプットを返すこと。なら理屈で言えば「可能性のあるすべてのインプットをテストすれば、すべての動作が確認できる」ことになります。

でもこれは、事実上不可能です。たとえば「名前を入力するテキストボックス」を考えましょう。入力のパターンは？「鈴木」「田中」「高橋」「(空白)」「a」「b」「c」…。パターンは無限に考えられます。

すべてのパターン（＝全数）をテストするのは、不可能なのです。これが「ソフトウェアにバグがないことを証明するのが不可能である」ことの最大要因です。

ではどうするか？できるだけ網羅性を失わないように、テスト条件を絞ります。例えばこのような考え方。

得られる結果のバリエーションを網羅するように、テスト条件を決定する必要があります。

できるだけ網羅性を保つように、テスト条件を絞ること。

早めにテスト

ソフトウェアの開発ライフサイクルは、一般的にこのように進みます。

ユニットテスト、結合テスト…と進むにつれ、多くのモジュールを組み合わせてテストすることになります。

ユニットテストのときは、バグ修正は簡単です。そのモジュール１つを直せばよいのですから。

テストが進むと、バグ修正のコストが格段に上昇します。組み合わせたモジュールすべてに影響が及ぶ可能性があるからですね。

なので、同じバグなら、可能な限り早めに取り除いたほうがよいのです。

「よし、ユニットテストでできるだけバグを取り除こう…」いやいやそれでは足りません。テストはもう、要件定義の時点から始まります。

矛盾した仕様、複雑なメッセージ、存在しないデータ…。いろいろな欠陥の芽が見えています。そこで欠陥が除ければ、そもそもコーディングで欠陥が埋め込まれることもないわけです。

できるだけ初期の段階で、欠陥を取り除いておくこと。

欠陥は偏る

ソフトウェアのバグは、さまざまなコードに万遍なく発生する、ということは、あまりありません。

たいていの場合、バグの発生する箇所はどこかに偏りをみせます。これは、実際にテストをしたことがあるなら、経験則的に分かるでしょう。

そのソフトウェアの中でも、複雑なアルゴリズム、多くのイベント制御するインターフェイス、そのようなコアな処理のモジュールに、バグは集中します。

これは、ソフトウェアテストにおける「パレートの法則」と言えます。

テストの中で、バグが発生するモジュールの傾向を見極め、テストリソースを集中させる。そうすれば、エラーの解決が早まります。

エラーが多いモジュールを分析して、テストリソースを集中させること。

殺虫剤のパラドックス

農作物に昆虫がつかないように、殺虫剤を撒きます。何度も繰り返し使用すると、撃退しようとしている昆虫が殺虫剤に対して免疫を獲得し、効果がなくなってしまいます。

この現象が、ソフトウェアテストにも当てはまります。同じセットのテストを繰り返しても、新しい欠陥を発見するのには役に立ちません。

あるソフトウェアを、改修するケースを考えましょう。

ソフトウェアに修正や改修を加えるなら、テストケースも一緒に見直す。そうしないと、テストの効果が落ちてしまいます。

テストケースは、いちど作ったあとも、継続的にレビューと修正を行うこと。

テストはコンテキスト次第

コンテキストとは「文脈、前後関係、事情、背景、状況」といった意味です。

コンテキスト次第というのは、つまりこういうことです。どのようなテストが必要かは、そのソフトウェアの目的や背景に依存する。

スマホアプリ、クラウドマイクロサービス、ロボット制御ソフトウェア…それぞれの特性に応じて必要なテストは変わってきます。どんなソフトウェアにも適用できるテストの種類や方法は、ないのです。

そのソフトウェアが重視するポイントを踏まえて、テストを実施すること。

エラー不在という誤信

ソフトウェアテストに関して、プログラマーがつい勘違いしがちなこと。それは、

エラーがない ＝ 高品質なソフトウェア

と思ってしまうこと。

大変なテストを乗り越え、ついにエラーをなくした瞬間。プログラマーは無常の達成感に包まれるでしょう。しかし忘れてはなりません。ソフトウェアは、エラーを０にすることが最終目標ではないのです。

考えてみてください。あなたがディーラーで車を買おうとしたときに、

この車は、ハンドルを回せば正しく曲がりますし、アクセルを踏めばちゃんと走りますよ！

そんなこと言われて、喜びますか？

ユーザーにとって、エラーが０なのは、至極当たり前のことなのです。

使いやすい、速い、きれい…ユーザーはそういった、機能定義としては現れない、非機能要件を求めます。それを確認するには、ユーザーと一緒にソフトウェアをテストしたり、ユーザビリティを初期のプロトタイプでテストしたりといった方法も考えられます。

バグを見つけるだけではなく、ユーザーのニーズや要件を満たしているかもテストで確認すること。

まとめ

ソフトウェアテストは、難度の高い作業です。それは、

という、相反する命題に答えを出す必要があるから、といえるでしょう。

完璧なテストはない、という事実を受け入れつつ、どうすれば限られたコストで最大限の効果を出すか、が重要です。

「ソフトウェアテストの７原則」を意識しながら、「完璧なソフトウェア」という、崇高の頂を目指しましょう。