リスクベースのテストやこの本で説明したPRISMAメソッドは、ジェームズ・バッハが1997年に考えた「十分なテスト」（Bach.1997）というコンセプトに非常によく関連しています。
この考えは当時テスト・コミュニティーを二分させました。
テストの専門家の片方の言い分としてはそれは、責任回避だとか妥協だとか単純すぎて有用ではないと主張し、さらにこれによって面倒な作業が発生するとも言っていました。
その一方リスクベーステストの支持者は、そもそも「完璧な」解決方法はなく、この方法が実プロジェクトの中でできる現実的な方法だと主張しました。
十分なテストのアプローチは、リスクベースのテスト手法の理解を助けます。
リスクテークされているプロジェクトにおける「リリースジャッジ」のための良いフレームワークです。
あなたはテスターとして次のように尋ねられたことはありませんか？「システムをリリースするために、十分なテストを実行しましたか？」と、このような大きな決断を下す時に、どうすればこの質問に答えられますか？
プロジェクトマネージャーから言わせれば「テスターは『う～ん、まだ十分ではないですね』といつも言っているのでテスター達はいつまでたっても決断できない」と思っています。
プロジェクトマネージャーはテスターを悲観主義者として認識しています。
もしあなたが「まあ、大丈夫でしょう」と言うとプロジェクトマネージャーはあなたの目の前に紙を突き出してサインオフ（署名）を求めるでしょう。
そのサインオフ（署名）をしたら、あなたは他人の責任を負えますか？
つまり「十分に良い」とはどのような状態でしょうか？また、リスクベースのテストはこの質問にどのように答えてくれるでしょう？
「十分に良い」というのは、テスト理論への形式主義に対する答えです。
「欠陥0」を目標とすることはソフトウェアにおいては合理的ではありません。
あなたは自分自身に対してはもちろん、ユーザーや顧客に対して「欠陥0」を目指していると偽ってますか？そうでないでしょう。
あなたの顧客やユーザーは現実世界に住んでいるのです。
妥協は避けられません。
あなたはいつも次から次へと現実が押し寄せ、そしてその先には不完全な情報に基づいて決定を下すことに挑戦しなければなりません。
テスターとして見積もりを減らしたり、テストの実行対象を絞り込んだりしても、どうか怒らないでください。
なぜならばどんなプロジェクトにおいても予算とリソースは常に制約されており、欠陥をゼロにすることはできないため、テストを絞り込む罪悪感と恐怖にさいなまれることは避けることはできないはずです。
システムをリリースする（または増強させる）という文脈において「十分」の定義は次のとおりです。
- 現在の状態で十分に価値を出せる事。
- 重大な問題がない事。
- その機能が作る価値は、残存する問題（重大ではない）が引き起こす可能性のある損害よりも十分価値がある事。
- 現在の状況、考えられているすべての事柄において、それを修正するためにリリースを遅らせたならば、利益よりも損害の方が大きい事。
この定義は、このシステムが本番で稼働し、価値を得、利益を得るために、十分に働いていること（このシステムの拡張を含む）を意味します。
「重大な問題はない」とは、使用不能または容認できなくなるような重大な障害を引き起こすような欠陥はないということ意味します。
現時点ではすべてのことを考慮して、完璧を目指して時間やお金を注ぎ込むよりも、既知の問題を抱えたまま早期にリリースする方がコスト的にメリットがあります。
このフレームワークは、利点が価値があると期待されている不完全な製品を時間通りにリリースすることを可能にします。
では、リスクベースのテストは、この「十分に良い」アイデアとどのように適合しているのでしょうか？
まず第一に、「十分な利益が得られているか」を確かめないといけません。
私たちが実行するテストでは、最低限利益を提供する機能が完璧に動いている事を実証する必要があります。
私たちはこれを証明しなければなりません。
第二として、重大な問題はありますか？という問いに答える必要があります。
インシデント報告つまりソフトウェアの欠陥の記録は、少なくとも重大な問題（および可能な限り多くの他の問題も含む）の証拠を提供しています。
そしてこれが十分であるために重大な問題はないはずと言えるのです。
第三にテストは決定を下すのに十分か？という事です。
テストによってリスクに対して修正され、十分に利益が本番リリースして得られると言えるような十分な証拠を提供しましたか？
本質的にはこれらのすべての質問に対してバランスを取ることが必要です。
十分な品質と許容可能なレベルのリスク抽出する事を提供するという目的で、テストにリソースを費やすのです。
図1：テストと品質とリスクのバランス
製品が十分かどうかを判断するのはテスターの責任ではありません。
ここで1つたとえ話を入れましょう。テスターを裁判における証人と見立ててみましょう。
このシーンの主なプレーヤーは次のとおりです。
-
被告人（システム）
-
裁判官（プロジェクトマネージャー）
-
陪審員（ステークホルダー）
-
証人（テスター）
今回のたとえ話では弁護士の役割出て来ません。
前提として裁判官と陪審員両名とも、証人からの証拠を抽出し、「事実」に対して議論する事に優れていると仮定します。
証人の役割に焦点を当ててみましょう。
証人は平等主義者（陪審員）に理解を促すために形式化され複雑な証拠を提示し説明するために法廷につれて来られた人たちです。
裁判官は、客観的かつ役割として分離されたものでなければいけません。
証拠から有罪または無罪どちらが言えるかと尋ねられた場合、証人は証拠に基づいてどのように論理を展開できるかこれから説明しますが、判断そのものは裁判官に委ねられています。
このたとえのようにテスターは、「これらの機能は動作し、これらの機能は動作せず、このリスクに対しては修正されており、このリスクは残っています」という証拠を表明するだけです。
これがシステムを受け入れられるかどうかはテスター以外の他の人が判断することです。
テスターは、ステークホルダーに決定を下すための情報を提供するために存在しています。
結局のところ、テスターはソフトウェアを開発したり欠陥を作り込むことはありません。
テスターはシステムを本番稼働できるかどうかを受け入れると言うリスクを冒しません。
テスターは、マネージャーや同僚に対して情報を提供するために独立した視点を提示する。
製品がリリースに対して十分かどうかを判断するように尋ねられたとき、テスターは得られた証拠に基づいてこれらの利点が利用可能であると発言する可能性はありますが、リスクは依然として存在するのです。
しかし、実プロジェクトにおいてテスターとして決定を下すように求められたら、どうしたらいいですか？
答えは、ステークホルダーが決定を下すのを最大限手助けしなければならないということです。
たとえば6ヵ月前にテスターから報告された、機能不全に陥れるような問題は現時点でまだ存在するかもしれません。
当時のステークホルダーとテスターの合意が得られているとするならば、リスクの認識を緩和しない限り、システムをリリースことはできません。
未解決のリスクについて以下の情報から判断が下される必要があります。
-
特定のリスクに対して修正されたと判断するのに十分な証拠がある事。
-
一部の機能が機能しない（リスクが発生している）という証拠がある事。
-
証拠の欠如（テストが実施されていないか、テストが計画されていないため）のリスク（の疑い）が残っているという事。
これは判断として理想的ではないように思えるかもしれませんが、
先述した非現実的な理想的な基準よりもましだと言えます。
あなたはそれでもなおシステムのリリース可否について意見を述べることを余儀なくされるかもしれませんが、私たちは、この原則的な立場をつまり裁判における証人という立場を、プロジェクトの早い段階できっちり表明することよって、マネージャーへの信頼性を高めると信じています。
マネージャーは、将来のプロジェクトで適切な責任を負う可能性があります。
これは開発者がテスト開始予定日よりも遅れてテスターに引き渡される時に発生します。
リリース日は固定されたままで変わりません。
開発フェーズ終了の基準は、テストフェーズが開始できるかを判断するために使われますが、開発フェーズが制限時間内に完了されない場合も多々あるかと思います。
しかしながら、リリースへの圧力は非常に大きく、この基準を脇に置きがちです。
この場合重大な欠陥があったりダウングレードしたりする可能性があります。
フェーズ終了判定は、プロジェクトの初期段階において理想的に考えられ制定されますが、これは残念ながら意思決定を容易にするものではありません。
テストの開始時になって明らかになったリスクが、全体にわたって見えています。
テストフェーズが短縮された場合でもリスクベースのテストをしていれば、いくつかのリスクに対して修正できた可能性があり、テスターが新たなリスクを明らかにした可能性はもちろんありますが、少なくとも危険性の高いリスクはすべての関係者にとって明らかになっています。
実際にリリースする決定が下された場合、ステークホルダーは、すべてのリスクに対して修正し、すべての利点が利用可能であるという証拠がだされる前に、製品がリリースできるということを明示的に選択しました。
リスクベーステストは単にテスターに対してだけに利益をもたらしません。ステークホルダーに対しても、その決定を下すのに十分な情報があると判断できました。
実際、リリースの決定を行うための情報は、テスト実行フェーズの初日から利用可能になります。
テストの証拠と残存リスクのバランスはリリース判定を大きく左右します。