はじめに
はじめまして！DX開発事業部 SQAグループの高良です。現在はテスト業務に従事しています。
私は2025年に入社し、それまで約10年はゲーム業界（ディレクターなど）に身を置いていました。
今回は、ソフトウェアテストに携わるようになって取得した資格「JSTQB」で定義されている
『テストの7原則』を紹介します！あわせて、実務においてどう活かしていくべきか整理してみたいと思います。
『テストの7原則』とは
『テストの7原則』というものを聞いたことはありますか？
これらは、ソフトウェアテストで提唱されている以下7つの原則を指します。
- テストは欠陥があることは示せるが、欠陥がないことは示せない
└ テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できない - 全数テストは不可能
└ すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である - 早期テストで時間とコストを節約
└ プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない - 欠陥の偏在
└ 通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する - テストの弱化
└ 同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる - テストはコンテキスト次第
└ テストに唯一普遍的に適用できるアプローチは存在せず、コンテキストによって異なる方法で行われる - 「欠陥ゼロ」の落とし穴
└ ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤りである
『テストの7原則』を一部ピックアップ
テスト担当者として、特に実務に馴染み深い3つの原則をピックアップして紹介します。
1. テストは欠陥があることは示せるが、欠陥がないことは示せない
テストで欠陥が「ある」ことの証明はできますが、
欠陥が見つからなくても、欠陥が「ない（ゼロである）」ことの証明にはなりません。
誤解を生む表現：「これだけテストしたので、もうバグはないです！」
正しい表現：「このテスト条件でテストした結果、バグは検出されませんでした。」
テスト担当者の役割は、テストを通じて潜在的な欠陥を極限まで取り除き、
欠陥が見つからなかった部分を増やしていくことで、最大限欠陥がない状態に近づけていくことだと考えます。
2. 全数テストは不可能
すべての入力値・前提条件・組み合わせを完全に網羅してテストすることを「全数テスト」と呼びますが、
極めて単純なソフトウェア以外ではこれを行うことは非現実的であるということを指します。
テスト担当者の役割は、リスク分析やテスト技法を用いて、テストケースを絞り込むことで、
限られたリソースで品質をより良くしていく手段を考えることだと考えます。
- 【例】
・リスク分析：将来起こりうるリスクや重要度によってテストの優先順位を決める
・リスクベースドテスト：上記の優先度に従い優先順位の高い箇所からテストする
・同値分割法（テスト技法）：同じ挙動が期待される入力値をグループ化し、代表値をテストする
・境界値分析（テスト技法）：欠陥の潜みやすい端（n以上・n未満など）の境界になる値をテストする
7.「欠陥ゼロ」の落とし穴
ソフトウェア開発において「欠陥ゼロ」を目指すことは理想的に思えますが、
「欠陥ゼロ」=「優れたシステム」に繋がるわけではないということを指します。
例えば、テストで検出した欠陥をすべて修正しても、
顧客のニーズや期待を満たさないシステムが構築される恐れがあるからです。
優れたソフトウェア開発とは、顧客のニーズやビジネスに最大限貢献できることが最も重要な目的であり、
テスト担当者としても上記のようなマインドを持ってテストに向き合うことが大切になります。
さいごに
ソフトウェアテストの真の目的は、単に欠陥をゼロに近づけることだけではありません。
システムが仕様通りに動作しているかを確認する「検証（Verification）」にとどまらず、
そのシステムが顧客のニーズに応えられているかを問う「妥当性確認（Validation）」まで踏み込んでテストを行うこと。
この視点が、テストを通じて顧客のビジネス成功に貢献するための、テスト担当者としての役割だと考えます。
今後も、テストの立場から、携わるシステムの品質向上に向けて、最大限貢献できるよう努めていく所存です！
簡単30秒