テストの7原則

JSTQB FLのシラバスによると、ソフトウェアテストには、長年にわたって提唱され、あらゆるテストに適用できる一般的なガイドラインとなっている「テストの7原則」があります。それぞれの原則についてわかりやすくまとめます。

1. テストは欠陥があることは示せるが、欠陥がないことは示せない（Testing shows the presence, not the absence of defects）

テストを実施することで「システムに欠陥が存在する」ことは証明できますが、いくらテストをして欠陥が見つからなかったとしても、「システムに欠陥が1つも存在しない（100%完璧である）」と証明することはできません。テストはあくまで未検出の欠陥を減らすための活動です。

2. 全数テストは不可能（Exhaustive testing is impossible）

ごく単純なプログラムを除き、すべての入力パターンや条件の組み合わせを網羅してテストすることは現実的に不可能です。そのため、すべてをテストしようとするのではなく、テスト技法を用いたり、リスクや優先度に基づいてテスト対象を絞り込み、労力を集中させる必要があります。

3. 早期テストで時間とコストを節約（Early testing saves time and money）

ソフトウェア開発の早い段階からテスト（要件や設計のレビューなどの静的テストや、動的テスト）を開始して欠陥を取り除くことで、後工程での手戻りや故障を防ぐことができます。結果として、プロジェクト全体の時間と品質コストを大幅に節約できます。

4. 欠陥の偏在（Defects cluster together）

システムの中で見つかる欠陥や、実際の運用時に発生する故障の大部分は、システム内の特定の「少数のコンポーネント」に集中する傾向があります（パレートの法則）。この偏在の予測や実績は、リスクベースドテストを行う際の重要な指標となります。

5. テストの弱化（Tests wear out）

同じテストケースやテストデータを何度も繰り返して実行していると、いずれそのテストでは新しい欠陥を見つけられなくなってしまいます。この「弱化」を防ぐためには、定期的にテストケースやテストデータを見直し、変更や追加を行う必要があります（ただし、リグレッションテストのような例外もあります）。

6. テストはコンテキスト次第（Testing is context dependent）

あらゆるソフトウェアに普遍的に適用できる「万能なテスト方法」は存在しません。金融システムとゲームアプリでテスト手法が異なるように、業界、システムのリスク、開発手法などの状況（コンテキスト）に合わせて、テストのアプローチを柔軟に変える必要があります。

7. 「欠陥ゼロ」の落とし穴（Absence-of-defects fallacy）

「要件通りにシステムを開発し、見つかった欠陥をすべて修正すれば、必ず成功する」と期待するのは誤り（思い込み）です。仕様通りに完璧に動いたとしても、それが「ユーザーの本当のニーズや期待を満たしていない」「ビジネスの目的に役立たない」システムであれば意味がありません。仕様通りかの「検証」だけでなく、ユーザーの役に立つかの「妥当性確認」も重要です。