TM-2.3.1 (K2)リスクベースドテストでリスクに対応するさまざまな方法を説明する。

リスクとは

悪いまたは望ましくない結果やイベントをもたらす可能性のこと。

プロダクトリスク

リスクがプロダクト品質におよぶ場合のことで、品質リスク、またはプロダクト品質リスクとも呼ぶ。

プロジェクトリスク

リスクがプロジェクト成功におよぶ場合で、計画リスクとも呼ぶ。

システムの品質リスクの例

* レポートでの不正な計算
* ユーザ入力に対する応答の遅れ
* 画面とフィールドの分かりにくさ
など

テストで品質リスクを軽減する例

テストで欠陥が明らかになった場合は、欠陥の存在を周知させ、リリース前にその欠陥に対応する機会を提供することで品質リスクを軽減できる。

テストにより欠陥が検出されなかった場合は、テスト条件の下でシステムが正しく動作したことを確認することで品質リスクを軽減できる。

リスクベースドテストの目的

* 明示的または暗黙的に、テストにより品質リスクのレベル全体を引き下げる
* 特にリスクレベルを受け入れ可能なレベルにまで引き下げる

リスクベースドテストの活動

* リスク識別
* リスクアセスメント
* リスク軽減
* リスクマネジメント

リスク識別

ステークホルダのリスク識別技法
* 専門家へのインタビュー
* 第三者によるアセスメント
* リスクテンプレートの使用
* プロジェクトの振り返り
* リスクに関するワークショップ
* ブレインストーミング
* チェックリスト
* 過去の経験の活用

リスクアセスメントとは

リスク識別を行った後に識別したリスクを調査し、それぞれのリスクを分類して、それぞれのリスクに関連する可能性や影響を判定すること。

リスクの分類

それぞれのリスクを、性能、信頼性、機能性などの適切なタイプに分ける。
一部の組織では、 ISO9126 [ISO9126](ISO 25000 [ISO25000]に改訂中)の品質特性を使用してリスクを分類しているが、多くの組織ではリスク識別で使用するのと同じチェックリストを、リスクの分類でも使用する。

リスクレベルを決定する

通常はリスクアイテムごとに、リスク顕在化の可能性および顕在化した際の影響を評価する。
リスクのレベルは、定量的または定性的に評価できる。ただし通常、リスクのレベルは定性的にしか確認できない。つまり、可能性が「非常に高い」、「高い」、「中程度」、「低い」、「非常に低い」などと表現できるだけで、可能性を具体的な精度を持つパーセンテージとして表現することはできない。
同様に、影響が「非常に高い」、「高い」、「中程度」、「低い」、「非常に低い」とは表現できるが、完全なまたは正確な金額で影響を示すことはできない。
だが、この定性的なリスクレベルのアセスメントが、定量的なアプローチより劣っていると考えるべきではない。

プロダクトリスクおよびプロジェクトリスクの可能性に影響する要因

* 技術およびチームの複雑性
* ビジネスアナリスト、設計者、プログラマの個人的な問題およびトレーニングの問題
* チーム内の衝突
* 供給者側との契約の問題
* チームの地理的な分散
* レガシーアプローチ対新しいアプローチ
* ツールと技術
* 劣悪なマネジメントまたは技術的なリーダーシップ
* 時間、リソース、予算、およびマネジメントのプレッシャー
* 早期からの品質保証活動の欠如
* 高い変更率
* 高い初期欠陥率
* インターフェースと統合の問題

プロジェクトリスクおよびプロダクトリスクの影響に対する要因

* 影響を受けるフィーチャの使用頻度
* ビジネス目標の達成に対するフィーチャの重要性
* イメージの悪化
* 業務の喪失
* 財政的、環境保護的、社会的損失または責任の可能性
* 民事上または刑事上の法的拘束
* ライセンスの喪失
* 妥当な回避策の欠如
* 故障の判明による否定的な評判
* 安全性

リスク軽減

リスクベースドテストは、計画での指定に従って、リスクをカバーするように、テストを計画、実装、および実行する。
テストの開発と実行に伴う工数は、リスクのレベルに比例する。
つまり、リスクが高いと、より精緻なテスト技法を使用し、一方、リスクが低いと、あまり精緻でないテスト技法を使用する。さらに、テストの開発および実行の優先度は、リスクのレベルに基づく。
一部の安全関連標準(たとえば FAA DO-178B/ED 12B、IEC 61508 など)では、リスクのレベルに基づいたテスト技法やカバレッジの程度を規定している。
さらに、リスクのレベルは、プロジェクト成果物のレビューの適用、独立性の度合い、テスト担当者の経験の度合い、および確認テスト(再テスト)と回帰テストの実行度合いの決定に影響を与える。

ライフサイクルにおけるリスクマネジメント

リスクマネジメントは、ライフサイクル全体で行うのが理想である。
重要なリスクは、特定のテストレベルで早期に対処するだけではなく、初期のテストレベルでも対処する(たとえば、性能を主要な品質リスク領域として識別した場合、性能テストをシステムテストで早期に開始するだけではなく、性能テストをユニットテストおよび統合テストでも実行する)。
ほとんどのリスクベースドテスト手法には、リスクのレベルを使用してテストの順序付けおよび優先度付けを行うための技法を含んでおり、テスト実行時にもっとも重要な領域を早期に網羅し、もっとも重要な欠陥の検出を確実に行うことができる。

縦型探索(depth-first)

高リスクのテストをすべて、低リスクのテストよりも先に実行したり、厳格なリスク順にテストを実行したりする。

横型探索(breadth-first)

サンプリングアプローチを使用して、識別したすべてのリスクアイテム からテストのサンプルを選択することもある。この方法では、リスクに基づいて選択に重みを付け、同時に、すべてのリスクアイテムを少なくとも 1 回はカバーするようにする。

リスクに関するテスト結果の報告

リスクベースドテストは、残りのリスクレベルについてテスト担当者が管理部門にレポートし、管理部門でテストを延長するか、あるいは残りのリスクをユーザ、 顧客、ヘルプデスク/テクニカルサポート、運用スタッフに移転するかを決定できる。
テストマネージャは各テストステークホルダが理解できる方法で、リスクに関するテスト結果を報告する必要がある。

例題