もし、あなたが一人のテストマネージャーとしてアサインされている場合どんなシナリオが考えられるでしょうか？
あなたはこのテストのための計画と予算を策定するミッションをおっています。
最初は妥当であり十分に考えられた計画を策定していました。
さてテストフェーズが近づくと、開発チームからまだ製品の準備が十分ではなく、テスト開始に間に合わないと報告をうけました。
時間的な制約であなたのテスターはいくつかのテスト実施ができないことがわかりました。
もちろんテスト期間短縮に反対したり、開発チームに対して間に合うようにお願いしたり、マネージャーにもっとテストにリソースを割り当ててほしいと主張することはできますが、この主張が通るとは限りません。
つまり想定よりも少ない予算と時間でできるテストをしなければなりません。
あなたは可能な限りこの製品に対してテストしなければならず、本番で問題なく動作することを確認する必要があります。
この状況をどう乗り切りますか？
もしあなたがテストを手抜きしたならば、それは品質が規準に達していないことに起因する問題が発生するでしょう。
一方もし、予定していたテストをすべて消化するように行動したなら本番リリースはあなたのせいで遅れるでしょう。
ここでは建設的な解決策が必要になってきます。つまりゲームを変更する必要があるのです。
マネージャーが理解できるような説明の仕方で、あなたが持っているタスクのうちどのタスクが不可能かマネージャーに説明しましょう。
同時に代替案を提示することも重要です。
そしてマネージャーは製品をリリースするミッションをおっていますが、同時にリリースした場合のリスクを理解する必要もあります。
1つの戦略として、適切な品質レベルを見つけることでしょう。
製品においてすべての欠陥を修正する必要はありません。
同時に必ずしもすべての機能が完璧に動作する必要はないでしょう。
場合によっては、部分的に製品品質を低下させることもオプションとして考えないといけません。
これによって、あなたは重要性の低い部分のテストを削減できます。
もう1つの戦略としては優先順位付けするということです。まず最も重要な欠陥を見つけるためにテストを優先順位付けしましょう。
だいたいのケースにおいて最も重要なことと「最も重要な機能」はほぼおなじ意味です。
「最も重要な機能」はどの機能がシステムの主目的を担っているかを分析し、その結果どの機能が重要であり、どの機能が重要でないかを調べることで見つけられます。
これによって多くの欠陥が予想される場所をテストするなんてこともできます。
もしも製品の最悪の領域を見つけられたならば、その周辺に対して重点的にテストを行えば、より多くの欠陥を検出できるでしょう。
多くの重大な欠陥が見つかった場合、マネージャーはテストにもっと多くの時間とリソースを割くように考えるでしょう。
実際のプロジェクトでは、最も重要なもの（セクション5で議論されている）と最悪のもの（セクション6で議論されている）の組み合わせて考える必要があるでしょう。
リスクベースのテストでは、特にチームがテストを中断する必要がある場合は常に、利用可能な時間内で最良のテストを行っているという状態を作らなければいけないことに注意してください。
システムレベルでは、まずアプリケーションで最も重要なことをテストする必要があります。
これは、機能の可視性、使用頻度、および欠陥が市場流出した場合のコストを総合的に考慮して判断できます。