テスト担当者が理解しておくべき「ソフトウェアテストの7原則」を分かりやすく解説

1．ソフトウェアテストの7原則

これまで50年以上の長きにわたり提唱されてきたさまざまなテストの原則が、使いやすくまとめられています。それでは詳しく見ていきましょう。

▼JSTQBの資格についてはこちらの記事も参照してください。

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

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

出典：テスト技術者資格制度 Foundation Level シラバスより

テストでエラーや故障が見つかったということは、あくまで「欠陥があった」という事実に過ぎません。

テストで欠陥が見つからない場合でも、テストを実施していない範囲には欠陥があるかもしれません。

ソフトウェアに「欠陥が存在しない」ということはテストでは示せないのです。

さらに、いくら大量のテストケースを実施しても、それが見当違いのテストケースであれば、欠陥は出てこないでしょう。

テストをして欠陥が出てこなくても安心することなく、テストケースが十分かつ適切であるかを確認しましょう。

原則2: 全数テストは不可能

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

出典：テスト技術者資格制度 Foundation Level シラバスより

ソフトウェアテストにおいて、すべてのパターンを網羅することはほぼ不可能と言えます。

例えば、入力値A、Bの積をCと出力するソフトウェアがあったとします。AとBの値が1～100の整数に制限されていたとしてもテストケースの組み合わせは1万通りにもなります。

実際のソフトウェアでは入力値も出力値もより膨大となり、ソフトウェアが動作するマシンの状態などの外部要因もテストパターンに関係してきます。そのような場合、テストで使用するパラメータの組み合わせは容易に天文学的数値に達してしまいます。すべての組み合わせをテストするには気の遠くなるほどの時間が必要でしょう。

このように、ソフトウェアで全数テストを実施することは不可能に近いです。

そのため、ソフトウェアの性質やリスクなどを勘案し、実施可能なテスト範囲に絞り込んで実施することが重要です。

先ほどの例では、AとBの入力が1～100の全組み合わせをテストするのではなく100なら正常に処理し、101であればエラーとなることをテストします（境界値分析）。

このようなテスト手法を学ぶことで、効率よく欠陥を摘出できるようになります。

原則3: 早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。

出典：テスト技術者資格制度 Foundation Level シラバスより

もしソフトウェアを納品する直前に欠陥が見つかった場合、プログラムを修正し、影響がある箇所をすべて再テストしなければなりません。家づくりで例えると、建物を建てた後に基礎工事からやり直すようなものです。

それに対して、プログラムを書いた直後のテストであれば、プログラムの該当する行のみを修正して再テストすれば欠陥を取り除くことができます。釘1本を打ち間違えても、抜いて打ち直せばいいだけなのです。

さらに、プログラミングを開始する前の段階、家づくりであれば設計図を作成する段階でミスに気付けば、実装段階で間違いが発生することもありません。この実装前に欠陥を見つけることを静的テストといいます。

このように、欠陥を見つけるのが早ければ早いほど修正コストは少なくなります。

テストはなるべく早期に実施するとともに、テスト計画においてテスト実施の順番も十分に検討しましょう。ソフトウェア全体に影響する機能や、欠陥が多く含まれそうな機能を優先的にテストすることでコストを抑えることができます。

原則4: 欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則2 で触れたことと同様）。

出典：テスト技術者資格制度 Foundation Level シラバスより

経済やビジネス用語として使われる「パレートの法則」はソフトウェアテストにも当てはめることができます。8割の欠陥は、わずか2割のプログラムに含まれていると言われています。

この原則を生かしてより効率的にテストを進めるためには、テスト結果を都度分析し、欠陥が多発している箇所がないか確認しましょう。多くの場合、機能や担当者ごとに欠陥は偏在しています。欠陥が多く埋まっている箇所が予測できれば、該当箇所のテストを強化しましょう。

原則5: 殺虫剤のパラドックスに注意

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。

出典：テスト技術者資格制度 Foundation Level シラバスより

害虫駆除にずっと同じ殺虫剤を使っていると、そのうち虫が耐性を持ち、殺虫剤がだんだん効かなくなります。ソフトウェアテストにおいても同様で、同じテストケースを繰り返し行なっても新しい欠陥を摘出できなくなるということです。

対策として、各工程でテスト観点を変えたり、開発者目線だけでなくユーザー目線でテストを設計したりするなど、さまざまな観点でテストを行なう必要があります。

原則6: テストは実施内容次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる。（2.1 節を参照）。

出典：テスト技術者資格制度 Foundation Level シラバスより

ソフトウェアの性質によってテストの実施内容や方法は大きく変わります。自動運転のソフトウェアであれば安全が最優先となるよう十分にテストを行なう必要があります。

一方で社内用の簡単なツールであればテストはある程度行い、ユーザーに提供してからブラッシュアップしていく場合もあります。これを実施すればどんなソフトウェアも完璧になる、という万能なテストは存在しません。

ソフトウェアそれぞれの特性を考慮してテストを行ないましょう。

原則7: 「バグゼロ」の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

出典：テスト技術者資格制度 Foundation Level シラバスより

欠陥がゼロであっても、高品質なソフトウェアであるとは限りません。

機能的な欠陥を無くそうと修正したことによって、セキュリティホールができたり、使い勝手が悪くなったりしては本末転倒です。

高品質なソフトウェアは機能性だけでは判断できず、セキュリティ対策や使い勝手、性能といった非機能要件によっても評価されます。

ソフトウェアテストは欠陥の数を少なくするためだけでなく、ユーザーの要件や期待を満たすために実施するのです。

まとめ

ソフトウェアテストの7原則は、テスト担当者なら知っておきたいソフトウェアテストの一般的なガイドラインです。

完全無欠なソフトウェア、および完全無欠なソフトウェアテストはありません。

しかし、過去の技術者のノウハウが詰まった「ソフトウェアテストの7原則」を活用することで、より少ないコストでよりよい品質のソフトウェアを作ることは可能です。

ソフトウェアテストの計画、ケース作成、実施、分析すべてにおいて活用して、よりよいソフトウェアを作っていきましょう。