ソフトウェアテストは「バグを見つけるため」に行うものではない。実施した範囲内で、これ以上「バグが見つけられない」ことを証明するために行うもの。
この業界の方々でも、けっこー間違えて認識している人がいますよね。
まず「モノ作り」の基本大原則に触れておきましょう。それは、
「人間とは、完璧からは程遠い生き物である」
ということです。そのため、必ずバグ（不良、欠陥）は存在します。しないわけがないのです。もちろん運よく、たまたまバグが無いなんてこともありますが、少なくともその人が「今後も絶対にバグが無い」ことを100%保証するものにはなりえません。だって運よく、たまたまなんですから。再現性の欠片もありません。
そのため、JSTQB（ソフトウェアテスト技術者資格）認定の運営組織が定義している「ソフトウェアテストの原則をまとめたもの」として、
ソフトウェアの７原則
のなかでも、いの一番に取り上げられています。
テストは「欠陥があることしか示せない」という言葉は、言い換えればテストは「欠陥がない」ことを証明できないということです。どれだけテストをやっても、
完全で、
完璧で、
これ以上できるところは決して存在しない
と言い切れるテストなんてできると思いますか？
少なくとも２つ目の原則「全数テストは不可能」である以上、絶対にできないと私は思っています。つまり、テストをいくら実施しても「欠陥が全て無くなった」という証明はできないのです。
言い換えれば、テスト工程完了時点で「バグ０件です」なんてセリフが出てきたとしても、それを証明することは不可能だと言うことです。それはたまたま「（今回行ったテスト内容に限り）バグ０件です」と言うだけであって、ソフトウェア全体にとってバグが０件であるかどうかは誰にもわかりません。
「全数テストがどのくらい不可能か？」と言う問題については、次の動画で確認してみてください。複雑な組み合わせパターンになればなるほど、不可能であることがわかると思います。
では、何が証明できるのか？
それは、
現在行っているテストの中では、
不良や欠陥が見つけられなかった
ことを証明しているにすぎません。
そしてそれ以上のことは絶対に証明できません。だって、行っていないテストまで保証できるわけがないんですもの。行った範囲のみ証明が可能で、しかも確実に証明しきれるかどうかはテストケース次第であり、どんなケースでも結果さえそれらしいものが出ればなんとなく証明できてしまう…という類のものではありません。
そのためソフトウェアテストでは、テスト観点やテスト内容がものすごく重要視されます。テストツールの使い方がどうとか、テスト方式／方法がどうとか、テストの結果バグがどれだけあった（バグ密度）とか、そう言う枝葉は二の次です。
そう考えればIPAの公開している「定量的品質予測のススメ」などを成果物品質の分析や証明などに用いようという考え自体がまったく明後日の方向を見ていることがよくわかります。
これはその名の通り「予測」するものです。
何を予測するか。
未来をです。
つまり、テスト工程を進める過程において進捗状況と同時に管理し、そのまま進めるとどのような品質傾向に進んでいくかを予測するために定量的な情報を管理しましょうと言っているにすぎません。信頼度成長曲線もゾーン分析も、それ単体では結果品質を評価することはできません。
観点や内容が『正しく』なければ、どんなツールを駆使しても、どんなテスト手法を選択しても、必要なテスト成果を導き出すことはできません。
たとえば、次のような例に対して定量的品質管理だけでは何も説明ができないことからもわかります。
例１
Ａ、Ｂ、Ｃ、3つの機能の総step数（プログラム行数）に対して10%のテスト密度を妥当と設定したとします。具体的な数字を100件と仮定します。
実際テスト件数は102件でしたが、その９割がA機能に偏っていました。
はい。このような場合、テスト密度10%さえ超えていればＢ機能やＣ機能も品質は高いといえるのでしょうか？
また
例２
Ａ機能に対して90件ものテスト件数があります。
Ａ機能単体のテスト密度を考慮すれば50件を打倒しているため、品質的には問題がないと判断しました。しかし、フタを開けてみるとプログラム全体の前半にテストケースが集中しており、後半は100stepに1件未満のテスト密度となっていました。
はい、こんな状態で「Ａ機能のすべてが品質的にバッチリです！」といえますでしょうか。
…言えませんよね。
これが「定量的品質管理は、品質保証には使えない」ことの証左です。
そこで、テスト観点やテスト内容など、そもそも「テストすることで品質を保証できるかどうか」という観点に大きく影響を与えるのが『設計』であり、『テスト設計』です。
これまでも何度も言ってきましたが、この工程間コミュニケーションを疎かにして保証できるソフトウェア品質なんてものは存在しません。
設計書とは、プログラミングする者にとっても、テストする者にとっても、非常に重要なカンニングペーパーみたいなものです。これを100%実現できているかどうかが品質を保証する上で重要なポイントとなります。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。