「テストの原則」は、テスト担当者が知っておくべき基本的なガイドラインです。この記事では、現役テスト技術者の視点から、これらの原則を具体的な事例とともに解説します。

【テストの原則】の内容

「テストの原則」とは、テストの基本的な考え方をシンプルにまとめたものです。ソフトウェアテスト技術者の国際的な資格認定団体であるISTQBによって提唱されました。

テストの原則とは、ソフトウェアテストを効果的に行うための基本的なガイドラインです。これらの原則を理解することで、テストの効率を高め、品質を向上させることができます。

なお、2018年版シラバスまでは「テストの7原則」となっていましたが、2023年版シラバスからは「７」を取り除き「テストの原則」へと変更されています。
ここでは現場の視点を交えつつ、テストの7つの原則について1つずつ解説していきます。

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

テストにより、テスト対象の「欠陥がある」ことは示せても、他に全く「欠陥がない」ことは証明できないという意味です。
テストを行うことによって故障が生じれば、そこに「欠陥がある」ことは確かに確認できます。けれどテストケースで網羅されなかったような、レアなケースで故障が起きないとは言えませんし、条件を変えてテストをしたら欠陥が見つかる可能性もないとは言えません。テストする回数を増やしたら、故障が生じる可能性もあります。その一方で、後述するように、考えうる全てのパターンを想定して膨大なテストケースを実施するのは不可能です。

つまりテストで欠陥を発見することはできても、それをもって他に一切の欠陥がないとは言えないわけです。
例えば、あるウェブアプリケーションで特定の操作を行った際に欠陥が発生した場合、その操作に欠陥があることは確認できます。しかし、他の操作や条件で欠陥が発生しないことを証明するのは難しいです。

2．全数テストは不可能

全数テストとは、考えうる全てのパターン（組み合わせ・タイミングなど）でテストを行うことを指します。仮に全数テストを行うとなると、膨大な数のテストケースを実行する必要が生じることになり、予算や納期の面からみても現実的には不可能です。
JSTQBのシラバスには、「全数テストの代わりに、テスト技法、テストケースの優先順位付け、リスクベースドテストを用いて、テストにかける労力を集中すべきである。」とあります。リスクベースドテストでは、システムの中で最も重要な部分や故障が発生しやすい部分にテストリソースを集中させます。

たとえば決済システムのテストでは、金銭のやり取りが発生する部分に重点を置くことが重要です。もし、お客様から全数テストを求められる場合には、その現実性と代替手段について丁寧に説明することが重要です。全数テストが不可能であることを理解していただき、リスクベースドテストや優先順位付けの重要性を共有することで、より効果的なテスト計画を立てることができます。

3．早期テストで時間とコストを節約

ソフトウェア開発の早い段階で行うテストのことを、「早期テスト」と呼びます。ソフトウェアテストは、できるだけ早期テストを行うことが理想的です。開発の早期段階で欠陥を取り除くほうが容易であり、さらにその後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことがないためです。

早期テストの具体的な方法としては、静的テスト（コードレビューや静的解析ツールの使用、仕様書や要求のレビュー）や動的テスト（ユニットテストやインテグレーションテスト）があります。これらの手法を用いることで、開発の初期段階で欠陥を発見しやすくなります。
また開発者は時間が経つごとに、そのソフトウェアの設計についての記憶が失われていきます。開発してすぐの方が、修正がしやすいという側面もあります。

ただし、早期テストの原則自体は正しいものの、ソフトウェアテストの現場ではこの原則通りにならないことも少なくありません。たとえば、せっかく早期テストを行ったとしても、担当者が多忙であることが理由で、開発作業の中に早期テストの指摘事項が含まれないこともあります。この問題を解決するためには、テスト自動化ツールの導入や、テスト専任チームの設置が有効です。

4．欠陥の偏在

ソフトウェアの品質は全ての部分において均一ではなく、特定の箇所に欠陥が集中していることが多く見られます。これを「欠陥の偏在」と呼びます。これは、「80：20の法則」とも言われる「パレートの法則」にも通じます。パレートの法則とは、全体の80%の結果が20%の原因から生じるという経験則です。ソフトウェアテストにおいても、全体の80%の欠陥が特定の20%のモジュールに集中することが多いと言われています。

ソフトウェアの各機能は、それぞれ構築の難易度は一定ではありません。例えば、ユーザーインターフェースの一部分は比較的簡単に構築できる一方で、バックエンドのデータ処理部分は複雑で欠陥が発生しやすいです。また、ソフトウェアは規模が大きくなればなるほど、より多くの開発者やチームに作業が分担されることになります。その開発者やチームごとにスキル差もあります。このような理由から「欠陥の偏在」が生じるわけです。

実際に、ソフトウェアの全ての機能において、満遍なく同じぐらいの量の欠陥が発見されるというのは聞いたことがありません。一方で、欠陥が集中している箇所や機能が特定できれば、その部分を優先して集中的にソフトウェアテストを実施し、欠陥の数をできるだけ減らすことも可能になります。探索的テストをリスクベースドテストと併用することで、特にリスクの高い領域に対して効果的なテストを行うことができます。リスクベースドテストは、システムのリスク評価に基づいてテストの優先順位を決定する手法であり、探索的テストと組み合わせることで、欠陥の偏在をより効率的に発見・修正することが可能です。

5．テストの弱化

内容は同じですが、2018年版シラバスまでは「殺虫剤のパラドックスにご用心」という原則だったものが、2023年版シラバスからは「テストの弱化」に変更されています。

「殺虫剤のパラドックス」とは、同じ殺虫剤を使い続けていると、害虫が耐性を持ち始め、その殺虫剤が効かなくなってくることを指しています。ソフトウェアテストにおいても殺虫剤の効き目と同じで、同じテストケースを繰り返しても新しい欠陥を見つけにくくなるという考え方です。しかし、元となる「農薬のパラドックス」という用語の意図から考えると誤用であるという指摘もあるため、明確化のために書き換えたのではないかと考えられます。また、比喩を用いないことで、より簡潔、明確で理解しやすい表現を目指したと推測できます。

各テストケースによって発見された欠陥は、1つずつ修正されているわけですから、再び繰り返しても欠陥が見つかりにくくなるのは当然のようにも見えます。新しい欠陥を発見できるようにするには、パターンを変えてテストするのが有効です。

しかし実際の現場では、同じテストケースを繰り返すことが必ずしも悪いとはいえません。機能の改修が進むことによって1度改修されたはずの欠陥が復活してしまっていたり、同じテストケースで発見できる別の欠陥が生じたりすることもあるからです。
現場においては、プログラムを修正した際に欠陥が生じていないか確認するための「リグレッションテスト」において、修正前と同じテストケースを改めて実施することがあります。一方で修正が全く行われていない状態において、同じテストケースを繰り返しても意味がない、というのは「テストの弱化」の原則通りです。

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

テストに唯一普遍的に適用できるアプローチは存在せず、コンテキストによって異なる方法で行われるという考え方です。以前は「テストは状況次第」という原則だったものが、2023年版シラバスより「テストはコンテキスト次第」に変更となっています。

「コンテキスト」とは、特定の状況や環境、背景に関連する一連の条件や要因のことです。ソフトウェアテストにおいては、プロジェクトの目的、制約、リスク、利用する技術、ユーザーの期待などがコンテキストに含まれます。「テストは状況次第」から「テストはコンテキスト次第」への変更は、テスト活動が単なる環境や状況に限定されず、より広範なコンテキスト（背景、目的、制約、リスクなど）を考慮する必要があることを強調する意図があると考えられます。これにより、特定のプロジェクトや製品の特性に応じた適切なテストアプローチが促進されることを意図しています。

たとえば、過負荷に耐えることが重視されるソフトウェアでは、負荷に関するテストが求められます。また、Eコマースのためのソフトウェアでは、一般的にあり得るどんな条件でも正確かつ安全に取引ができるか確認するためのテストが必要です。

企業のコーポレートサイトでは、多種多様な環境から閲覧されることになるため、ブラウザや端末のシェア率などからテスト端末を選定し、正しく表示が行われるか、ページ遷移が設計通りかの確認を行います。一方、業務系のソフトウェアでは、使用環境（OS・ブラウザなど）が限定されるため、その環境でのみのテストを行います。

7．「欠陥ゼロ」の落とし穴

「『欠陥ゼロ』の落とし穴」とは、テストで見つけた欠陥を全て修正したからといって、必ずしもソフトウェアの品質が向上するわけではないという考え方です。これは、欠陥の修正が他の問題を引き起こす可能性があるためです。

たとえば、欠陥を修正した結果、ソフトウェアの動作が大幅に遅くなってしまうことがあります。この場合、欠陥がなくなったとしても、ユーザー体験が悪化するため、品質が向上したとは言えません。また、ソフトウェアテストの段階では機能が正常に動作するかに注目しがちで、ユーザーの使い勝手（ユーザビリティ）が軽視されることもあります。
さらに、使い勝手を良くすることが必ずしも品質を高めるわけではないケースもあります。例えば、ゲームの世界では操作性が良くなり過ぎると、ゲーム性が損なわれることがあります。ソフトウェアの性質や方針によって、「品質が高い」と言える状態は異なるため、単に欠陥をゼロにするだけでは不十分です。

このように、ソフトウェアの品質を向上させるためには、欠陥の修正だけでなく、ユーザーのニーズや期待、ビジネスゴールの達成に役立つかどうかを総合的に考慮する必要があります。検証に加えて、妥当性確認も実施することが重要です。

なお、こちらも2018年版シラバスまでは「『バグゼロ』の落とし穴」という原則でしたが、2023年版シラバスから「『欠陥ゼロ』の落とし穴」に変更されています。「バグ」はコードの不具合を指すことが多いですが、「欠陥」はそれに加え、設計や要件、ユーザー体験に関連する問題も含みます。この変更により、テストの対象がより広範で包括的なものであることを認識し、品質全体を向上させることを意図している可能性があります。また、シラバス全体としても「バグ」ではなく「欠陥」という表現を採用しており、表現の統一という側面も考えられます。

まとめ

ソフトウェアテストの原則を理解することは、テスト作業を効率的かつ効果的に進めるための鍵です。これにより、無駄な作業や方向性の違う取り組みを避けることができ、より効率的に欠陥を発見することが可能になります。

また、ソフトウェアテストには限界があることを認識することも重要です。すべての欠陥を見つけることは不可能であり、リスクとどのように向き合うかが大切です。リスクベースのアプローチを取り入れることで、限られたリソースを最も効果的に活用し、品質向上を図ることができます。
これらの原則を日々のテスト業務に取り入れることで、より効果的なテストを実施し、ソフトウェアの品質を向上させることができます。ぜひ、実際のテスト現場で活用してみてください。