5.製品の最重要部分を見つける
テストとは常にサンプリングであり、すべての状態をテストすることはできません。どんなにサンプリングしたとしても、テストできる箇所は無限に見つけられます。
したがって、どのプロジェクトにおいてもテストするものとテストしないものに関して意思決定を行う必要があります。
どこを重点的にテストするか、どの部分はそうでないのか。
テストフェーズの目標は、最悪の欠陥をテストフェーズの初期に見つけ、可能な限り多くの欠陥を見つけることです。
これを確実に行うためには、製品の中で最も重要な機能や特性を見つけ出す事が非常に重要です。
できるだけ多くの欠陥を見つけることは、製品の欠陥が多く集まる領域に対して重点的にテストすることが重要です。
言い換えるならば、より多くの欠陥が埋め込まれていると予想される場所を知る必要があります。
これについては次のセクションで説明します。
まずは、製品の最も重要な領域を知る必要があります。
このセクションでは、製品の領域を優先順位付けする方法について説明しましょう。
ここで紹介する方法は唯一無二のものではありません。
製品によってはいろいろな要素があるかとおもいますが、ここに挙げられている要素は多くの製品やプロジェクトで利用できるでしょう。
重要な領域は、特定の機能や機能グループもしくはパフォーマンス、信頼性、セキュリティーなどの品質特性として定義されるでしょう。
この本では、領域を一般的な用語「テスト項目」と呼んでみましょう。
テスト項目の重要性を判断する際に考えられる要素は次のとおりです。
クリティカルエリア（故障した場合のコストが大きいもの）
製品をとりまくさまざまな環境で製品を使用し、故障する可能性のある使い方を分析する必要があります。
そのようなクリティカルな故障を引き起こす可能性のある使いすべて、最低でも最悪の使い方を見つけます。
冗長性、バックアップ機能やまた、ユーザー、オペレーター、アナリストが使うであろう使い方を考慮しましょう。
レビューされていなくて、実際にプロセスに対して直接インストールされた製品は利用する前にちゃんと出力をレビューされている製品に比べてクリティカルでしょう。
製品がプロセスを管理する場合、このプロセス自体が分析対象となります。
ランク付けすると次のようになるでしょう。
ランク1:故障によって製品が壊滅的な状況になってしまう事象:たとえばこの故障によってシステムが停止されたり、環境内のタスクをストップさせる（ワークフロー、ビジネスや製品全体を停止させうる）可能性があるもの等です。また故障によって甚大な金銭的損失を生じさせたり、人命に対して損害を与える可能性のあるものも含まれます。
ランク2:故障によって製品に損害を与える事象:製品全体が停止することはありませんが、データ欠損をおこしたり、破損したり、プログラムやコンピューターが再起動されるまで機能不全になる可能性があるものが含まれます。
ランク3:故障によって動作が妨げられる事象:たとえばユーザーの仕事を停止させたり、難しい手順を実行しないと同じ結果に到達できないもの等です。
ランク4:故障によってユーザーの迷惑になる事象:この故障は機能には影響しませんが、ユーザーや顧客にとっては望ましくないものが含まれます。
もちろん、製品ごとに故障が与える影響はさまざまです。
たとえば（人間の）安全性に関連たり、財務上の損害を与えうる製品対しては故障は非常にクリティカルです。
もう1つの方法としては、マーケティングの視点を使うことで重要性を判断できるでしょう。
たとえばこの製品の（ユニークな）セールスポイントは何かを考えることです。
表示領域
もしも何か故障が生じた場合、表示領域は、多くのユーザーに対して障害を与えうる領域です。
ユーザーとして考えないといけないのはスクリーンの前に座っているオペレーターだけではなく、出力されたレポートや請求書などを見ているエンドユーザー、またはソフトウェアを含むこの製品によって提供されるサービスに依存している製品のユーザーの場合もあります。
この章では、そのような故障に対するユーザーの許容範囲を考慮すべき要因として考えないといけません。
さまざまな機能や品質特性の重要性に関するものに関しては、前の章を参照してください。
使用方法に関して訓練を受けていない、または使い慣れていないユーザー、特に一般の人々を対象としたソフトウェアは、UIに注意を払う必要があります。
頑健性(ロバストネス)も大きな懸念事項になります。
ハードウェアや生産プロセス、ネットワークなどと直接つながって作用するソフトウェアは、ハードウェア障害やデータのノイズ、タイミング問題などの外部の影響を受け易いでしょう。
この種の製品は、環境が変化した場合を考慮して徹底した検証や有効性の証明、再テストが必要です。
可視性に関しては、外部の可視性（組織外）と内部可視性が区別されることが多く。それによって自分のユーザーだけがその問題を経験しているのかどうかということが分けて考えられます。
最もよく使われているエリア
製品の中で一部の機能は毎回使用されているのに対して、一部の機能は数回しか使用されていないということがあるでしょう。
また一部の機能は、たくさんのユーザーが利用しているのに対して、一部の機能は少数のユーザーしか使ってないということがあるでしょう。
使用される頻度に応じて機能に優先順位を付けます。
特定の機能領域のテストをスキップするためには優先順位付けが必要です。
四半期に1回とか半年に1回または一年に1回だけしか使われない等、たとえば使用頻度で決められます。
このような使用頻度の少ない機能は、「最初にリリースしてしまってみんなが使用する前にテストする」ということも可能でしょう。
しかし、使用頻度分析が明確にできないこともあります。
そのような例としては、たとえばプロセスを制御するようなシステムにおいては、特定の機能が外部から見えない場合があります。
そのような場合の対処方法としては、システムの設計部分まで詳細に見ることで分析できます。
こちらもランク付けすると次のようになるでしょう。
ランク1:不可避な領域：通常利用シーン（スタートアップ、印刷、保存など）中にほとんどのユーザーが接触するであろう製品の領域。
ランク2:頻繁に利用される領域：ほとんどのユーザーが最終的には接触する製品の領域ですが、特定の利用シーンに関しては接触しない可能性がある領域。
ランク3:時々利用される領域：一般ユーザーに関しては一度も訪れたことがない領域かもしれないが、より専門的、もしくは使い慣れたユーザーにとっては必要とする機能を扱う製品の領域。
ランク4:ほとんど利用されない領域：ほとんどのユーザーが一度も訪れることのない領域もしくは、特定のユーザーが特定の行動を取る場合にのみ接触する、製品の領域。
これとは別で重大問題を引き起こす故障は依然としてクリティカルです。
重要な要件を選択するための別の方法としては、（A Cost-Value Approach for Prioritizing Requirements Karlsson et al 1997）を参考にしてみてください。
テストの実行が開始された後、いくつかの欠陥が見つかった場合、これらを分析してテストにさらに集中し、テストの方法を調整できます。