3.9は、リスクに関して。
リスクとは、
将来、否定的な結果を生む要素。通常、影響度と発生可能性として表現する。(JSQTB用語集)
と定義されます。PMBOKでは、ポジティブな結果につながりうる要素もリスクに含んでいましたが、ここではネガティブ要素のみですね。
リスク・マネジメントの大まかな流れは、以下の3つのステップ。
リスクの識別
テストに限った話じゃありません。関係者でブレストしたり、有識者とレビューを行ったり、リスク抽出のためのテンプレートを使ったり。様々な方法でリスクを洗い出します。FMEA（Failure Mode and Effect Analysis：故障モード影響解析）もその技法の1つです。
リスクの分析
洗いだしたリスクの分類や定量化を行ないます。
よく言われるように、リスクはその発生確率と、発生した際の影響度で図られます。発生確率や影響度を、それぞれたとえば5段階評価し、その積をリスク大きさとして定量化することもありますね。
リスクの軽減
分析したリスクを小さくすることを検討します。
軽減の方針は、以下の4つ。
- リスクの発生確率を小さくする。
- リスクの影響度を小さくする。
- リスクを他の人/部門に引き取ってもらう（保険など）。
- リスクを無視して受け入れる。
設計工程における十分なレビューは、実装段階で欠陥が混入するというリスクの確率を下げるでしょう。機能間の独立性の高い設計を行うことで、ある機能に欠陥が含まれるというリスクの影響が下がるでしょう。
テストについていえば、ソフトウェアが「誤った動きをすることを認識する」ことも、「正しい動きをすることを確認する」ことも、ともにリスク軽減となります。
※テストを行おうと行わまいとソフトウェアの欠陥の数は変わらないはずであり、テストを行うことで何故リスクが軽減できるか考えると、確率論の闇に飲まれるので目を背ける
重要なのは、このリスクマネジメントの活動がプロジェクトを通じて行われるということ。新しいリスクの識別、既存リスクの再評価、軽減策の有効性評価というループが回ることになります。
リスクベーステスト（Risk-based Testing）のコンセプトはいたってシンプルで、リスクの大きさに応じて、テストケースの工数の割り当てや、順序の設定を行うというものです。
順序の設定の方法は、以下の2つに分けられます。
- 縦型探索（Depth-first）：リスクの大きい順にテストを行う
- 横型探索（Breadth-first）：すべてのリスク要素に対し一度はテストを行う
・・・いや、もっと深い技法なのでしょうが、それについてはきちんと勉強してから書きます。
