テストの7原則

過去50年以上のソフトウェアテストの歴史から導き出された、テストに関する7つの普遍的な原則です。

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

テストによって「バグがあること」は証明できますが、どれだけテストしても「バグがゼロであること（完全性）」は証明できません。

テストは「未発見の欠陥が残っている確率」を減らす活動です。

2. 全数テストは不可能

すべての入力パターン、すべての組み合わせ、すべてのパスをテストすることは、極めて単純なプログラムを除いて物理的に不可能です。

したがって、リスク分析や優先順位付けを行って、テストの焦点を絞る必要があります。

3. 早期テストで時間とコストを節約 (Early Testing)

開発の後半でバグが見つかるほど、修正コストは跳ね上がります（要件定義のミスをリリース直前に直すのは大変！）。

シフトレフトのアプローチを取り、SDLCの初期段階からテスト活動（レビュー等）を開始すべきです。

4. 欠陥の偏在 (Defect Clustering)

「少数のモジュールに、大多数の欠陥が集中する」という法則です（パレートの法則）。

テスト実行時には、この集中箇所を予測して重点的にテストを行うことが効率的です。

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

同じテストを何度も繰り返していると、そのテストでは新しい欠陥を見つけられなくなります（虫が殺虫剤に耐性を持つのと同じ）。

新しい欠陥を見つけるには、テストデータやテストケースを定期的に見直し、更新する必要があります。

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

開発対象によって、テストのアプローチは変わります。

• 安全性が最優先の「航空機の制御システム」
• スピードが最優先の「モバイルゲーム」

これらに対して、同じテスト手法・同じ厳密さでテストを行うことはありません。

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

「バグが見つからない＝良いソフト」とは限りません。

もしシステムが使いにくかったり、ユーザーの要望を満たしていなかったりすれば、たとえバグがゼロでも、そのシステムは失敗です（検証はできたが、妥当性確認に失敗した状態）。