ソフトウェアテストの7原則について
ソフトウェアテストの7原則とは
ソフトウェアテストの7原則（Seven Principles of Software Testing）とは
ソフトウェアテストの7原則とは、ソフトウェアテスト技術者の国際的な資格認定団体であるISTQBが提唱しているソフトウェアテストの原則です。
この原則は、ソフトウェアの品質基準を設定し、テストプロセスを最適化する考え方を提供するものです。
またこれは、ステークホルダに対して、ソフトウェアがリリース可能な状態にあるという根拠を説明することに役立ちます。
ソフトウェアテストに対する誤解とは？
ソフトウェアテストとは、仕様に定められていない振る舞いやバグを見つける作業のことです。
言い換えると、テストとは「求められている機能を果たせるか否か」を確認することです。
そして、テストが目標とする品質は、試験項目にすべて合格することです。
つまり、ソフトウェアテストの目標とは、すべてのバグを取り除くことではありません。
「テストを実施すれば完璧なソフトウェアが作ることができる」と考えている人がいるかもしれません。
しかし、これは誤解であり、不具合の全くない完璧なソフトウェアを生み出すことは実際には不可能です。
なぜなら、完璧なテストを実施することは不可能（極めて困難で現実的ではない）だからです。
7つの原則について
【原則１】テストは欠陥があることは示せるが、欠陥がないことは示せない
Testing shows the presence of defects, not their absence.
この原則は、「テストによって全ての欠陥を見つけることはできない」ことを認識するべきである、という考え方です。
これは、ソフトウェア開発において、利害関係者の期待を設定するのに役立つ考えです。
「欠陥が存在しないこと」を証明することは、所謂「悪魔の証明」であり、これを証明することは不可能です。
つまり、テスト工程完了後にQA（品質保証）チームが欠陥ゼロを報告しても、それはソフトウェアにバグがないことではありません。
実際にはバグが存在する可能性はあるものの、QAチームがそれを見つけられなかったということになります。
（欠陥が検出されない最も一般的な理由は、テストケースが全てのシナリオをカバーしていないことです。）
【原則２】全数テストは不可能
Exhaustive testing is impossible.
全数テストとは、考えうる全てのパターンでテストを行うことを指します。
組み合わせパターンというものは条件次第で幾何級数的に増加するため、そのようなテストは現実的ではありません。
ソフトウェアテストでは、予算面や納期を考慮して、重点的に実施するテスト箇所を絞り込むことが必要です。
標準的なブラックボックステストとホワイトボックステスト戦略を使用してテストケースの数を最適化します。
そして、ソフトウェアが「求められている機能を果たせるか否か」を確認することこそが最も重要なことです。
【原則３】早期テストで時間とコストを節約
Early testing saves time and money.
早期テストとは、開発の早い段階で行うソフトウェアテストのことです。
開発の早期段階でバグを検出できれば、その修正は容易であり、低コストで達成できます。
英語圏で「時を得た一針は九針を省く（a stitch in time saves nine）」という諺があるように、ソフトウェアテストも早期対応することが最も効果が高い方法となります。
かつてIBM が実施した調査によると、設計段階で「1ドル」で修正できるものが、テスト段階では「15ドル」、実稼働システムで問題が見つかった場合は「100ドル」のコストがかかるという試算が出たことがあります。
【原則４】欠陥の偏在
Defects cluster together.
欠陥の偏在とは、ソフトウェア品質は全体で均一ではなく、特定の箇所に欠陥が集中することが多いという意味です。
これは、発見される欠陥や運用時の故障の大部分は、少数のシステムコンポーネントやモジュールに集中するという経験則や統計値からの提言となります。
この原則は、パレートの法則（全体の80%の結果が20%の原因から生じるという経験則）の一例としてよく取り上げられます。
言い換えると、「欠陥の80％は、全体の20％にあたるソースコードに起因する」ということです。
つまり、ソフトウェアテストでは、リソースを全体に均質化して配置しても効果が薄いということです。
欠陥の偏在を予測し、観察結果に基づいてリスク分析を行うことで、効率的で効果的なテストを実施することが可能となります。
【原則５】殺虫剤のパラドックスにご用心（テストの弱化）
Beware of the pesticide paradox.
殺虫剤のパラドックスとは、同じ殺虫剤を使い続けると害虫が耐性を持ち、いずれその殺虫剤が効かなくなることを指します。
つまり、この原則は、同じテストを繰り返すと新たな欠陥の検出に対する効果は薄れてくるので、テスト項目やテスト方法は定期的に見直すことが大切であるという提言となります。
※以前は「殺虫剤のパラドックスにご用心」という原則でしたが、2023年版シラバスからは「テストの弱化」に変更されています。
同じテストケースを繰り返しても新しい欠陥を発見されにくくなることは当然であり、新しい欠陥を発見するにはパターンを変えてテストすることが有効です。
とはいえ、プログラムを修正した際に欠陥が生じていないか確認するための「リグレッションテスト/デグレードチェック」において、修正前と同じテストケースを改めて実施することは非常に有意義ですので、以前のテストケースを破棄しろという話ではないことに注意が必要です。
【原則６】テストは状況次第
Testing is context-dependent.
テストは状況次第とは、ソフトウェアの性質や実行環境などによって、テスト方法を柔軟に変えるべきという考え方です。
ソフトウェアテストには、全てのケースに当てはまる唯一の戦略というものはありません。
テスト対象毎にテスト観点やテスト条件を洗い出し、最適なテストケースを作成する必要があります。
【原則７】「バグゼロ」の落とし穴（欠陥ゼロの落とし穴）
Absence-of-errors is a fallacy.
バグゼロの落とし穴とは、テストで見つけた欠陥を全て修正できたからと言って、必ずしも品質を向上させるとは限らない、という原則です。
つまり、仮に潜在バグを0件に減らすことができたとしても、それがソフトウェアの品質につながるわけではないという考え方です。
※以前は「バグゼロ」となっていましたが、2023年版シラバスからは「欠陥ゼロ」に変更されています。
この問題は、要するに不具合と品質は直結しないという提言です。
例えば、修正によりバグは少なくなったが、修正影響により速度性能が低下してしまい、ユーザにとって操作性の悪いシステムになってしまうということです。
WindowsとLinuxを比較した場合、性能がよく不具合も少なくカスタマイズ性に富んでいるのはLinuxです。逆に不具合だらけで性能もよくないOSといえばWindows（特に後期のWindows10や初期のWindows11）です。しかし、売れていて多くのユーザを抱えているのはWindowsです。これは、大多数のユーザにとっての利用しやすさなどを重視しているための結果といえます。