【JSTQB/ISTQB FL 4.0解説】1.3 テストの7原則とは？図解でわかる「Testing Principles」完全解説

ソフトウェアテストの世界には、「7つのテスト原則（Testing Principles）」と呼ばれる重要な考え方があります。

ISTQB Foundation（JSTQB Foundation相当）のシラバス第1章「1.3 Testing Principles」では、この原則を理解することがテストエンジニアにとって欠かせない知識とされています。

この記事では、初心者でもわかる形で「テストの7原則」をやさしく解説します。

✅ テストの7原則とは？

ISTQBが定義する7つのテスト原則は、ソフトウェアテストの基本的な考え方をまとめたものです。

これらを理解することで、テストの目的や効果を最大限に発揮することができます。

No	原則名	概要
1	テストは欠陥の存在を示すが、その不在を証明できない	テストは「バグがある」ことを示せるが、「バグがない」ことは証明できない。
2	網羅的テストは不可能	すべての入力・組み合わせをテストするのは現実的に不可能。限られた時間とリソースで最適化する必要がある。
3	早期のテストは時間とコストを節約する	要件定義や設計の段階でテストを開始することで、バグ修正コストを大幅に削減できる。
4	欠陥は集中する傾向がある	不具合は特定のモジュールや機能に集中する傾向があるため、重点的にテストする領域を見極めることが重要。
5	同じテストの繰り返しは効果が薄れる（テストの疲労）	同じテストケースを繰り返すだけでは新たな欠陥を見つけられない。テストケースを定期的に見直す必要がある。
6	テストはコンテキスト依存である	医療系、金融系、ゲームなど、システムの種類によってテストの手法や優先順位は変わる。
7	バグがない＝良い製品ではない（欠陥の不在の誤り）	バグがなくてもユーザーの要求を満たさないなら、それは失敗した製品である。

どれだけ多くのテストを行っても、「バグが完全にない」とは言い切れません。

テストは「問題があるかもしれない場所を特定する」行為であり、「完全な品質保証」ではありません。

この原則は、テスターや開発者が「テストで完璧を証明しよう」としないための重要な心構えです。

例えば、ログイン画面で「ユーザー名」と「パスワード」を入力する場合でも、組み合わせは無限にあります。

すべてのケースをテストすることは不可能なため、同値分割法や境界値分析などのテスト技法を活用して、最小限で最大の効果を得る必要があります。

不具合を「要件定義」や「設計段階」で見つけるのが理想的です。

なぜなら、後工程になるほど修正コストが上がるからです。

テスト担当者は開発初期から仕様書レビューや設計レビューに参加し、**静的テスト（レビューや検証）**を積極的に行うことが推奨されます。

全モジュールが均等にバグを持つわけではありません。

多くの場合、複雑なロジックや頻繁に修正される箇所に不具合が集中します。

過去のバグ履歴や変更履歴をもとに重点的なテストを行うと、効率的に品質を向上できます。

同じテストケースを何度も実行しても、新たな欠陥を見つけることは難しくなります。

「回帰テスト」のスイートを定期的に見直し、新しい不具合傾向に合わせたテストケースの更新が必要です。

この考え方は「殺虫剤のパラドックス（Pesticide Paradox）」として知られています。

テストの方法はプロジェクトによって異なります。

例えば、安全性が最優先の航空システムと、ユーザビリティが重要なECサイトでは、テスト戦略もまったく違います。

システムの目的・リスク・ユーザー層に合わせてテスト方針を決めることが大切です。

テストの目的は「バグをゼロにする」ことではなく、「ユーザーの期待に応える製品を提供すること」です。

どれほど欠陥がなくても、使いづらかったり要件を満たしていなければ失敗です。

**テストは「品質保証」ではなく、「価値の確認」**でもある、という意識を持ちましょう。

ISTQB/JSTQBで学ぶ「7つの原則」は、単なる試験対策ではなく、現場でテストを設計・実行する上での「思考の指針」です。

これらを意識して行動することで、より価値のあるテストができるようになります。