このセクションでは、PRISMAメソッドを使用して製品のリスクアセスメントを実施する際のプロセスに関して詳細に説明していきます。
図3：PRISMAプロセスの概要
PRISMAプロセスの中心テーマとしてはいわゆる製品リスクマトリックスの作成です。
前のセクションで説明したように、影響の大きさと欠陥の可能性からテストする各項目（リスク項目）に関する因子が決定されます。
影響の大きさと欠陥の可能性の両方に対して点数付けすることで、リスク項目に関して製品リスクマトリックスを作成できます。
標準的なリスクマトリックスは4つの領域（象限I、II、III、IV）に分かれており、それぞれ異なるリスクレベルとタイプを表現しています。
リスクレベル/タイプが異なれば、それぞれに対して異なるテストアプローチがテスト計画書に記載されるはずです。
図4：製品リスクマトリックス
PRISMAプロセスをサポートするために、フリーソフトウェアのサポートツールが開発されています。
このツールを使った例は、この本の後半部分で使われています（図5,6,8など）。
もし、すぐに製品の最悪の領域を見つけられたなら、それの領域に対してより多くテストができ、より多くの欠陥を発見できます。
重大な問題が多く見つかった場合、これはしばしばマネージャーにより多くの時間とリソースをテストに割くように動機づける事につながります。
構造された計画の段階は常に成功の鍵となります。
計画中に、インプットとなるドキュメント（テストベースと同じことを指すことが多い）を特定し、収集します。
もちろん、関連するドキュメントはリスク分析対象のテストレベルに大きく依存します。
ドキュメントが要求された品質レベルであることと、このプロセスで使用できる項目（テスト項目と呼ばれる）がちゃんと含まれていることを確認する必要があります。
このフェーズでの テストベースは「最終的である」または「受け入れ済みである」必要はないのですが、製品リスク分析に使用するのに十分安定している必要はあります。
ギャップ（例：要件）を特定し、ドキュメントオーナーに報告する必要があります。
もしテストベースが先述したレベルで利用可能でない場合は、製品リスク分析プロセスを継続する方法を考えたりとそもそもこのプロセスを続行するかどうかを検討する必要があります。
理想的には、ここでいう使用するドキュメントは、要件定義書（システムレベルでのテスト用）またはアーキテクチャを表したドキュメント（開発テスト用）を指します。
リスクアセスメントに使用される項目は、テストベースやリスク項目に基づいて識別されます。
リスクが想定される場合（たとえば、ドキュメントのあいまい性に関連する項目等）、これらはドキュメント化されるべきです。
最も確度高くこれらを識別するには、ドキュメントオーナーやステークホルダーとミーティングしてインタービューをする必要があります。
経験則として、プロセスを現実的にすすめるためにはリスク項目はだいたい30〜35項目を超えない位がおすすめです。
つまり、ドキュメントに記載されている項目（要件など）を論理別な単位で分割し、グループ化する必要があります。
識別されたリスク項目は、階層構造で構成されます。
個別のリスク項目として要求ドキュメントに記載されているすべての要件を記載することは、あまり有益はありません。
テスト戦略に応じて、プロジェクトによっては、より高いレベルのリスク分析結果を入力として使用し、後工程でコンポーネントまたはサブシステムごとの基本要件を評価するために、個別のより詳細な製品リスク分析は後回しにすることを決定する場合があります。
識別されたリスク項目リストは、一意に識別され、プロジェクト全員が理解できるものでなければいけません。
各リスク項目は参照IDとして数字で表すことも構いませんが、プロジェクトで意味のあるコードまたは省略形で表現されることもあります。
リスク項目ごとに、可能であれば、テストベースの関連部分にリンクを貼る必要があります。
リスク項目ごとに1行ずつ説明を追加する場合もあります。
プロジェクトメンバーにとって、この説明は、リスク項目を評価しなければならないという明確な動機を与える表現であるべきです。
製品リスク分析では障害が発生する可能性ともし本番で発生した場合の影響度という2つの成分で分析します。
セクション5と6でこれらの2つの成分について議論したように、影響度や尤度に影響を与えるいくつかの因子を使用することをおすすめします。
テストマネージャーは、プロジェクトが尤度と影響の観点からリスク項目を評価するためにどの因子を使用するかを決定します。
テスト戦略において、リスク因子の標準セットはすでに組織レベルで決定されているのが理想的です。
もちろん、プロジェクトによっては、テスト戦略で決めたリスク因子の標準セットから逸脱したものが存在する場合があります。
さらに、各因子は数値化されている必要があります。
さらに、これらの値は単なる数字ではなく「5個未満のインターフェイス」、「10個以上のインターフェイス」などと意味のある説明で表示されることが好ましいでしょう。
可能であれば、値は客観的かつ測定可能な意味を持つ必要があります（例：「中規模」という表現ではなく<1 KLOCとか）。
しかしながら、現実的な運用上、1,2,3や1から5または0,1,3,5,9などの数値セットが使用されることが多いでしょう。
まず手始めに適用するなら、最も簡単な方法、低（1）、中（2）、高（3）で表現するのも良いでしょう。
純粋にテストの観点だけを考えると、0,1,3,5,9の表現の方がベターです。なぜなら"9"が他の値と比較して明確に区別され、高いリスクであることをより明確に識別できるからです。
1,2,3や0,1,3,5,9など、どの数値セットを使うかは、プロジェクトレベルよりも組織レベル等高いレベルで事前に決定されていることが好ましいでしょう。
1つの因子2倍がより重要と考えられる場合、重み付けを使用することも可能です。
たとえば、ある因子は、別の因子よりも2倍の「価値」を持つと表現できます。
因子の重み付けは、テスト戦略ですでに決定されている事が好ましいが、プロジェクト固有の目的に合わせて調整することもできます。
一般的な方法としては、重み付けを各因子に掛けて、システムの各領域に対して加重和を計算することです。
結果的に最も重要性が高い（点数が高い）領域に対して集中的にテストしてください！
選択したすべての因子に対して相対的な重み付けをかけ合わせます。
長く時間をかければ非常に厳密に計算できますが、多くのケースで、重み付けは3つで十分です。
つまり重み付けの値として1,2,3のどれかを使います（1:そんなに重要ではない因子、2:中程度重要な因子、3:影響が強い因子などです。
プロジェクトをいくつか進めていくうちに履歴としてデータが蓄積されたなら、つけた重み付けを微調整できます。
製品リスク分析に関与するステークホルダーが特定され、選出されます。
一般的に、ビジネスやプロジェクト内のいろんなロールで選出されます。
例としては、プロジェクトマネージャーや開発者、ソフトウェアアーキテクト、マーケティング、エンドユーザー、ビジネスマネージャー、アプリケーションエンジニアなどです。
ステークホルダーの選出は重要なタスクであり、重要なステークホルダーを見逃せば、「関連するリスクが特定されていない」と彼に指摘されてしまいます。
理論的には、ステークホルダーはおのおの個別にどの因子が重要かという意見を持っていますが、実運用上は、ステークホルダーに関連する、すなわち彼の役割に関連する因子だけを彼にアサインすることが有益でしょう。
典型的には、ビジネス影響を及ぼす因子をビジネス担当者にアサインし、障害の可能性に関する因子は技術の専門家（ソフトウェアアーキテクト、シニアエンジニア等）にアサインすべきでしょう。
明らかに心理的要因が絡んでくるため（自分が関連する因子の重要度を上げたがる、ビジネス担当者はビジネスに関連する因子を重み付けしたくなる）この段階では重み付けを使用しないルールにしましょう。
すなわち各ステークホルダーは同等に重要であると考えましょう。
各因子を少なくとも2人のステークホルダーにアサインすることは特におすすめです。
アサインを担当するテストマネージャーは、次の点で良好なバランスを取る必要があります。
-
テストレベルに応じて役割に適切な人を選択する。
-
影響度因子は「ビジネスロール」に、尤度因子は「技術ロール」に埋めてもらうようにする。
-
影響度因子と尤度因子の両方について、十分な知識を含んだ上、検討する。
最後にスコアリングプロセスに適用されるルールを設定しましょう。
リスク分析の一般的な落とし穴の1つは、結果がクラスター化してしまう傾向があることです。
つまり、結果は、すべてのリスク項目が互いに近い状態の2次元行列になってしまうことです（すべての因子が最重要など）。
これを効果的に防止するには、ステークホルダーにはすべての因子に対してフルレンジ（1-3や0-9の値のすべてを使う事）でスコアリングするようなルールとするのが良いでしょう。
このルールはPRISMAプロセスをサポートします。
ルールの例としては、「すべての値が使用されなければならない」、「すべての因子が採点されなければいけない」、「空白は許可されない」、「因子に割り当てられた値は均質な分布を取っていないといけない」等です。
テスト実行の後半部分では、前半で欠陥が発見された領域に焦点を当て、さらに検出された欠陥と同じ種類を対象としたより多く、かつ深いテストを実行する必要があります。
ドキュメントが要求された品質レベルであることと、このプロセスで使用できる項目（テスト項目と呼ばれる）がちゃんと含まれていることを確認する必要があります。
このフェーズでの テストベースは「最終的である」または「受け入れ済みである」必要はないのですが、製品リスク分析に使用するのに十分安定している必要はあります。
任意プロセスではありますが、テストマネージャーはキックオフミーティングを開催して、全ステークホルダーにこのプロセスにおけるそれぞれの役割を説明する機会を設けられます。
任意ではあるのですが、キックオフミーティングは強くおすすめします。
なぜなら、キックオフミーティングを行ってしまえば、このプロセスにおいて、すべての参加者それぞれに対して期待される行動は明白になるはずです。
キックオフミーティングは、リスク項目、因子のリストを説明し、どの因子に重点を置く必要があるかを明確にするためにも利用されます。
リスク分析のキックオフ段階では、PRISMAプロセス、リスクベーステストのコンセプト、製品リスクマトリックスだけでなく、この活動の目的も明確化されます。
明確に説明することや共通の見解を作り出すことは、スムーズな運営とステークホルダーそれぞれのモチベーションアップに貢献します。
プロセスの有効性と期待される利益についての説明は、プロセスの後半ではなく、ここのキックオフで展開されるべきです。
ここで共有される項目は次のとおりです。次のプロセスである個々の準備のやり方、使用するツールの説明、タイムスケジュールについて説明します。
テストマネージャーは、キックオフの後の残りのプロセスの概要も共有します。
ステークホルダーには、このフェーズの後半で開催されるコンセンサス会議において何を期待し、さらにプロセスの最後には何が起こるかを明確に説明すべきです。
テストマネージャーは、ステークホルダーに対して、このPRISMAプロセスの役割と貢献がプロジェクトのテストアプローチにどのような影響を与えるかを説明します。
リスク項目と因子については、ステークホルダーに採点を依頼する際に詳細に説明すべきです。
もちろんリスク項目、因子、採点スコアそのスコアそれぞれの正確な意味も、明確にして置く必要があります。
この採点で信頼できる結果を得るには、リスクアセスメントのすべての特性について共通の理解が必要です。
キックオフミーティングの終わりには、ステークホルダーからのコミットメントを得る必要であり、彼らが意欲的に参加することを促す必要があります。
このフェーズでは、参加者は、リスク項目の各因子に対して値を割り当てます。
それぞれのリスク項目に関して対応する因子の予想されるリスクに対して、最も適した値を選択することによってスコア付けしていきます。
この手順は手動で行うこともできますが、スコアシートの自動チェックをサポートするExcelシートを提供することで、スムーズに行えるでしょう。
図5：参加者のスコアシートの例（PRISMAツールから）
ステークホルダーが記入した値は、予想されるリスクに基づいています。
つまり各ステークホルダーは何か不具合が生じる可能性がある（欠陥の可能性がある）、もしくは、ビジネスにとって重要なもの（欠陥の影響）を予想して採点しています。
予想されるリスクは、多くの場合、ステークホルダーの個人的な前提に基づいています。
これらの前提もドキュメント化する必要があります。
後で、コンセンサスミーティングにおいて、これらの前提は、スコアの比較、予期しない結果や外れ値を説明するのに非常に役立ちます。
たとえば、なぜ私たちはこのようにスコアをつけたのですか？そして、私たちはもしかして異なる前提を持ってましたか？など。
それぞれの値を、テストマネージャーが事前に決定したルールと照合していきます。
たとえば、選択した値は十分に分散されており、ステークホルダーにすべてアサイン済みの因子はスコア付けが完了しているかどうかなど。
特定の因子について採点する際には、可能な限りさまざまな値の間で（できるだけ）均等な分布になることが重要です。
これは、有益な製品リスク分析をするには不可欠です。
値のアサインは絶対値ではなく、相対値です。
たとえばどの因子が最も頻繁に使用されるのかとか、最も複雑な因子かとかなど。
スコア処理中に高い値と低い値の両方を使用することにより、より差別化されてスコアリングでき、これは後工程でより明白にテストの優先順位付けができます。
採点の例:
良い例（均等な分布）:
| リスク項目 | 複雑度 |
|---|---|
| 001 | 低 |
| 002 | 高 |
| 003 | 中 |
| 004 | 低 |
悪い例（不均等な分布）:
| リスク項目 | 複雑度 |
|---|---|
| 001 | 高 |
| 002 | 高 |
| 003 | 中 |
| 004 | 高 |
表1：良いスコアリングの例と悪いスコアリングの例
もしこのフェーズを初めて行う場合、テストマネージャーは、参加者に対してサポートを行います。プロセス、ルール、場合によっては各因子を詳細に説明します。
このフェーズではテストマネージャーは最初に、個々のスコアの採点中にスコアが正しく付けられたかどうかをチェックします。ルール違反がある場合は、テストマネージャーがこれに関して該当参加者とちゃんと話し合う必要があります。
おそらくこれが発生した場合の解決策として、因子や値の意味を明確にすべきか、もしくはいくつかの追加の前提を作り、ドキュメント化しなければいけないかもしれません。
テストマネージャーは、参加者が前提をドキュメント化しているかどうかも確認する必要があります。
必要に応じて、該当する参加者に対しては前フェーズの個別の準備を（部分的に）やり直してもらう必要があります。
各因子に対して少なくとも2つ以上の異なるスコアがつけられていた場合、テストマネージャーが検査を行う必要があります。
ルール違反をステークホルダーとテストマネージャーがどうしても解決できない場合は例として次のような対応をとることになります。
彼らは「スコアの均等分配」が特定の因子に適用できないこと（全部優先度高など）を主張する場合、これはコンセンサスミーティングで議論の対象となります。
スコアの提出期限が近づいているとき、テストマネージャーはステークホルダー達に時間内にスコアを提出するようにリマインドすべきです。
期限内に提出しなかったステークホルダーに対しては、個別にアプローチしてください。
プロセスの次のフェーズに進むには、少なくともプロジェクトのステークホルダーまたは役割にアサインされた各グループからの代表的なスコアの提出がないといけません。
テストマネージャーは、個々のスコアを計算して平均値を出します。
彼はまた、コンセンサスミーティングで議論されるべき課題リストも準備します。
各リスク項目について、不具合の可能性および影響度が決定されていきます。
つまり、リスクごとの項目で、尤度を決定する因子のスコアが合計され、影響度因子のスコアが合計されます。
各リスク項目は、いわゆるリスクマトリクスに配置できます。
現時点では、コンセンサスミーティングで議論される課題リストの候補はすべて未解決です。
ルールの違反：
-
先述したように、ステークホルダーと一緒にテストマネージャーがルール違反をエスカレーションすることを決定したとき。
-
すべての評価フォームの合計結果が未解決のリスク項目につながった場合。因子に対するアサインされたすべての値の分布が所定のしきい値を超える場合、リスク項目は「未解決」として判断されます。たとえばあるステークホルダーが特定のリスク項目に関する同じ要素に対して最も高い値を割り当てたのに対して、別のステークホルダーが最小値を割り当てた場合などです。
-
また図の6のリスクマトリックス円内のように、すべての象限のボーダーライン上にあるつまりリスクマトリクスの中心に寄りすぎているリスクアイテムも議論の対象となるでしょう。
しきい値およびそのほかのルールは、計画フェーズ中にテストマネージャーが設定したプロジェクトルールに基づいて決定されます。
レビューされていなくて、実際にプロセスに対して直接インストールされた製品は利用する前にちゃんと出力をレビューされている製品に比べてクリティカルでしょう。
製品がプロセスを管理する場合、このプロセス自体が分析対象となります。
リスクの追跡は、プロジェクト全体を通じて行う必要があります。
これは、リスク分析の一部を定期的に繰り返すことによって、また初期リスク分析を繰り返し評価することによって実行できます。
コンセンサスミーティングの冒頭でテストマネージャーからミーティングの目的が説明されます。
このミーティングの最後に、（認識される）製品リスクについて共通の理解が達成されるべきです。
最終的な結果は、ステークホルダーがコミットし、ルールセットを遵守するリスクマトリックスで表現されなければなりません。
しかし、全スコアに関して、全員のコンセンサスを取る必要は必ずしもなく、時には不可能な場合もあるでしょう。
結局、各参加者は、自分が抱えている背景と役割に応じて、特定のリスク項目の重要性に関して独自の関心と意見を持っています。
図6：リスクマトリクスの例（PRISMAツールから）
ミーティング中に、未解決リストの項目がステークホルダーの間で議論されます。
これはテストマネージャーが、お互い合意に達し、それぞれの主張を理解することを目的としています。
議論は、ドキュメント化された前提を使用して因子ごと、リスク項目ごとに行われます。
多くの場合、異なるスコアリングは要求の異なる理解に起因しています。
この場合、それぞれの理解が明確化されていないため、要件の変更リクエストにつながります。
ディスカッションの終わりに、最終的なスコアが決定され、結果として製品リスクマトリックスが表示されます（図6参照）。
この結果得られるマトリックスは、ステークホルダーとともに常に検証されるべきです：
「マトリックスが期待どおりのものか、それとも予想を反した結果がありますか？」結果がステークホルダーの期待通りでない場合は、（再）検討する必要があります。
常識は唯一の判断軸ではなく、さまざまな判断方法の一部にすぎません。この常識を使いすぎると危険です。
会議の最後に、テストマネージャーは結果を要約し、製品リスクについて共通の理解が達成されているかどうかをチェックします。
必要に応じて、フォローアップミーティングを開催することもあるでしょうし、小規模グループに分かれての特定のディスカッションミーティングを開催することもあるでしょう。（例：要件を担当するチームがミーティング中に質問を提起された場合等。）
1つのプロジェクト内で、複数の製品リスクマトリックスを作成できます。例としては、
-
受け入れテストのマトリックスとサプライヤーテストのリスクマトリックス。
-
マスターテストプランレベルのマトリックスと特定のテストフェーズのマトリックス。
複数のリスクマトリックスが作成されるときは、いつも一貫していなければなりません。
つまり、より低レベルのテスト計画に、より高いレベルのテスト計画からマトリックスの部分だけを再利用することは可能でなければいけません。
たとえば、下位レベルのテスト計画ではリスクマトリックスのステークホルダーを選出する場合、ビジネスリスク（インパクトファクター）を評価するステークホルダーを選出しないことがあります。
その代わり、ビジネスリスクに関しては上位レベルのテスト計画からコピーされます。
一貫性を保つとは、複数のマトリックスに存在するリスク項目が同等のスコアを有することを意味しています。
より高いレベルのテスト計画からのリスクマトリックスのリスク項目が、より低いレベルのリスクマトリックスでいくつかの項目に分割される場合、これらの項目の平均リスクスコアは、より高いレベルの製品リスクマトリックスのリスク項目のスコアと同等でなければいけません。
リスクマトリクス内のテスト項目の位置に基づいて、すべてのテスト項目が優先順位付けが決定されます。
その結果、すべてのテスト項目の実施順序が決定されます。
最初に実施されるべきは最も重要な項目です。
加えて、優先順位付けされて、テスト項目に分解されたテストアプローチは、リスクマトリックスにおけるそれぞれの位置に基づいて定義される必要があります。
通常、テストアプローチは、テストの深さとテストの優先順位の2つの重要な側面を持っています。
テスト深さに応じて、異なるテスト設計手法を用います。
たとえば、リスクの高いテスト項目についてはデシジョンテーブルを使用し、リスクの低いテスト項目には同値分割を使用する等の色を付けます。
注意しなければいけないこととしては、テスト深さに応じたテスト設計手法の適用は、すべての（テスト）プロジェクトに対してこの手法を適用できるほど十分に成熟しているわけではないということを念頭においてください。
多くのテストプロジェクトは依然として要件を満たすテストケースのみを作成し、テストデザインを実施していません。
異なるテスト設計手法を使用するという方法以外に、結果のリスクマトリクスに基づいて個別にテストアプローチを定義する代替案があります。
たとえば、静的テスト、テストデザインのレビュー、再テスト、回帰テスト、テスト実行の独立のレベルを高める事、およびステートメントのカバレッジ目標などの終了基準などです。
また、リスクの高い因子は、経験を積んだテストエンジニアをアサインするとはリスクを軽減する別の方法です。
ここで言及したテストプラクティスと、それらを使用して差別化テストアプローチを定義する方法について考えてみましょう。
-
静的テスト:識別されたリスクに基づいて、リスクの高い箇所を入念にレビューを行うことなどです。危険性が高いと思われる領域の入念なチェック等。
-
テストデザインのレビュー:リスクの高い領域では、テスト設計（またはテストケース）をステークホルダーまたは他のテスターと一緒にレビューすることもできるでしょう。
-
再テスト:再テスト（確認テストとも呼ばれます）では、不具合が修正された後、リスクに応じて全テストを再実行するか、不具合が生じたした手順だけを再実行しするかを選択します。
-
回帰テスト:もちろん、リスクアセスメントの結果を回帰テストにも適用できます。それによって、回帰テストのケースやリソースを最もハイリスクな領域に対して集中的にカバーする用に調整する必要があります。
-
テスト実行の独立のレベルを高める:一人のテスターがテストケースとテスト手順を定義し、別のテスタがテスト手順を実行します。その利点としては、独立したテスト実行者は、テストケースとその実行方法にとってより批判的に捉える傾向があり、その結果、より多くの欠陥を見つけられる可能性が高くなります。コンポーネントテストの場合、2人のプログラマーペアを作り、お互いのソフトウェアをテストしたりもします（ペアプログラミング、一人がテストコードを書き、もう一人がそのコードをパスするようにコードを書く）。
-
テストの終了基準:それぞれ異なるリスクレベルに対して、それぞれ異なる終了基準(完了基準とも呼ばれる)を、適用できます。リスクカバレッジの高い領域では、要件カバレッジまたはコードカバレッジ基準を厳格に定義する必要があります。
他に終了基準に利用できるメトリクスとしては、実行されたテストケースの割合、未処理の欠陥の数、および欠陥検出率などが含まれます。
製品のリスクアセスメントの結果は、開発プロセスにも影響を与える可能性があることに注意してください。
開発プロセスで選択いかんによっては、残存製品リスク、特に欠陥を発生させる可能性に強く影響を及ぼします。
当初、製品リスクマトリクスの内容は、プロジェクトの初期段階での認識されるリスクに基づいています。
プロジェクト中に、テストマネージャーは、変化状況、そこで得られた情報に基づいてマトリックスをアップデートする必要があります。
DDP（欠陥検出率）、（変更された）前提、更新された要件やアーキテクチャのようなこのプロセスの外で観測されるインジケーターも含まれます。
プロジェクトの範囲、状況、要件の変更は、しばしばリスクアセスメントプロセスステップのやり直しを必要とします。
したがって、リスクアセスメントプロセスは反復的実行されます。
製品の中で一部の機能は毎回使用されているのに対して、一部の機能は数回しか使用されていないということがあるでしょう。
また一部の機能は、たくさんのユーザーが利用しているのに対して、一部の機能は少数のユーザーしか使ってないということがあるでしょう。
使用される頻度に応じて機能に優先順位を付けます。