テストの7原則

テストで共通に使える、一般的なガイドラインとなる７つの原則 である。

→ 以下7つ、

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

2.全数テストは不可能

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

4.欠陥の偏在

5.殺虫剤のパラドックスにご用心

6.テストは状況次第

7.「バグゼロ」の落とし穴

---（以下、jstqbシラバスからの引用です）

1.3 テストの7原則

これまで50年以上にわたり、さまざまなテストの原則が提唱され、あらゆるテストで共通に使える一般的なガイドラインとなってきた。

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

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。

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

2.全数テストは不可能

すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。

全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。

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

ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる（3.1節を参照）。

4.欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。

テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則2で触れたことと同様）。

5.殺虫剤のパラドックスにご用心

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。

この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する）。

ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。

6.テストは状況次第

状況が異なれば、テストの方法も変わる。

例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。

また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1節を参照）。

7.「バグゼロ」の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、

原則2と原則1により、これは不可能である。

また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。

例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

..

これらのテスト原則およびその他のテスト原則の例については、『Myers 2011』、『Kaner 2002』、『Weinberg 2008』、および『Beizer 1990』を参照されたい。

（おわり）

---