システム開発においては、常にプロジェクトQCD必達は追い求められます。しかし、度々起こる仕様変更や、予期しないトラブルの発生などにより、大きくプロジェクトの計画から逸脱してしまうこともあります。そのようなときには、どうにかテスト期間を短縮できないか、テスト項目をさらに圧縮できないか、と検討することもあるのではないでしょうか。
しかし、やみくもにテスト項目を削減すると、本来は削減すべきではないテスト項目を削減してしまうことになりかねません。そして、市場に欠陥を流出させてしまう可能性につながります。こういった事は避けたいものです。どうにかしてテスト項目を削減したいけど、どれが大事なテスト項目なのかを、判断するのは難しいと感じているのではないでしょうか。
こういったときに「リスクベースドテスト」の考え方を取り入れることで、優先度の高いテストが何かを見極められるようになります。「リスクベースドテスト」とは、「リスク」に基づいてテストの優先順位や範囲を決定する、ソフトウェアテストのアプローチの一つです。
ソフトウエア開発/テストプロジェクトにリスクベースドテストを取り入れよう！
そもそも「リスク」ってなに？ まずはテスト計画段階からリスクを洗い出そう
「リスクベースドテスト」に触れる前に、そもそも「リスク」の定義についてみてみましょう。「リスク」とは、は様々な定義がされていますが、簡単に言うと、「心配事」です。これから起こりそうな心配事を頭の中で「こんなことが起こりそうで、少し心配だなぁ…」と思っているだけではなく、机上に取り出して、目に見える形から始めます。
まずは、「リスクが管理された状態」をめざします。リスクが管理された状態とは、どういうことでしょうか？
＜リスクが管理された状態＞
- リスクが文書化されている
- リスクが分類されている
- リスクの発生確率と発生した際の影響が評価されている
- リスクへの対応策が検討されている
- リスクへの対応実施後の経過観察が行われている
- 新たなリスクの抽出ができる
テストの計画段階から様々なリスクが見え隠れしているはずです。これらを「リスク管理表」などに整理します。一人の担当者だけでリスクの洗い出しをすると、内容に偏りがでることがあります。立場や役割によって、心配事のネタは違うので、様々な立場の人を巻き込むのが大切です。すでにプロジェクトの「リスク管理表」がある場合には、テストに関係するリスクがあるかどうかを見ることも忘れずに行います。
＜リスクを洗い出す際のポイント＞
- リスク抽出は、リスク管理担当者やPM/PLだけでなく、プロジェクトメンバー全員で行う。
- 既存のプロジェクト「リスク管理表」がある場合、テストに関係するリスクかどうかを判断。
テストの専門家が体系化した3つのメニューから構成された
ソフトウェアテストの教育サービス
ソフトウェア品質教育サービス「バルカレ」のご紹介
＜リスクを洗い出す方法の一例＞
以下は、リスクを洗い出すときに参考になる方法です。時間をかけずにリスク抽出する方法として、週報会などの場で付箋を数枚ずつ渡して、その場でリスクを書き出してもらうと、５分くらいであっという間にリスク抽出ができるのでおすすめです。（ブレーンストーミングに近い方法）
抽出されたリスクは文書化して、プロジェクト内で共有するようにします。
| 手法 | 説明 |
| ブレーンストーミング | ビジネスやプロダクトに責任を持つステークホルダーと開発者、品質担当者、マネージャ、リーダー、メンバーなどが数人のグループを作り、ブレーンストーミングを行い、リスクを洗い出す。 |
| アンケート | 関係部門、メンバーにアンケートを実施。その結果からリスクを洗い出す。 |
| チェックリスト | 過去に発生した問題に関するチェックリストを用意。状況が該当するかをチェックする。膨大化したチェック項目は形骸化を生みやすい点に注意。 |
| RBS(Risk Breakdown Structure) | リスクが見えるレベルまで要素を分解して構造化。 |
リスクベースドテストの流れ
以下は、リスクベースドテストの全体の流れです。（図参照）
- リスクの抽出
はじめに、テスト計画をおこないますが、その中では、まずリスクの洗い出しを行います。すでに分かっている既知のリスク、それに加えて、プロジェクト特有のリスクを整理します。抽出されたリスクは、性質の異なる「プロジェクトリスク」と「プロダクトリスク」を分類して管理すると良いでしょう。
- リスクの評価と優先順位付け
リスクは、その発生確率と発生した場合の影響度を評価の軸とします。
影響度については、ビジネス上の機会損失などによる具体的な損失額や、発生した場合に掛かるリカバリーコストなどを基準にする場合もあります。
リカバリコストの例…データ漏洩、不正アクセス、認証の脆弱性が発生した場合の対応コストなど
ビジネス上の機会損失の例…収益への影響、顧客の信頼度、市場シェアの喪失など
- リスクの対応策を策定
優先度の高いリスクから対応策の検討を行います。
| 項目 | 内容 | 例：地震リスクへの対応 |
| リスクの回避 | リスクそのものを無くす | 地震が多い所から移転 |
| リスクの分散 | 悪影響を及ぼす範囲を狭め、 トータルのダメージを軽減する | 地震に備えて重要インフラを 地方に分散 |
| リスクの軽減 | リスク顕在化する確率や 顕在化した時のダメージを低く抑える | 地震に備えて免震構造に改築 |
| リスクの転嫁 | リスク顕在化した時のダメージを他に負わせる | 地震保険に加入 |
| 顕在化時の対策 | リスク顕在化した時の対策を予め準備しておく | 地震に備えて避難訓練 |
| リスクの受容 | リスクがあることを受容して腹をくくる | － |
- リスクのテスト戦略策定
プロジェクトリスクは、コンティンジェンシープラン（事前対応策・行動手順）も含めて検討を行うとよいでしょう。プロダクトリスクは、リスク低減策として、どのようなテストを実施する必要があるか検討し、テスト戦略およびテスト計画に反映します。例えば、DB変更にともない、COBOLからJavaへのプログラムの変更を行うケースがあります。この際に性能劣化が発生するリスクが見込まれる場合、以下のようなテスト戦略が検討できるでしょう。
1.単体テストで各処理の性能検証を行う（オンライン/バッチ）
2.システムテスト後に非機能テストとして性能テストを実施する
- テスト設計
テスト設計の手法はさまざまあります。ここでは、弊社でよく活用するテスト設計についてご紹介します。テスト設計では、テスト対象について以下の３つに分割して考えます。これらを組み合わせていくことで、ヌケモレが起こりにくいテスト設計を実現します。
- どのテスト対象の“機能（要素）”に対して
- どのようなテストの“観点” （確認する内容）を
- どの“条件／入力値”で行うのか
- リスクの監視、再評価
対策がきちんと効いているか、リスクが低減されたか、それを監視する。もしくは状況が変わってきているのであればリスクの再評価を行う。
- 新たなリスクの抽出
新たなリスクがあれば、リスク抽出、評価・分析を行う。
リスクベースドテストの活用事例を見てみよう
リスクベースドテストを取り入れた際の効果は、プロジェクトによって、または対象システムによって大きく異なります。図は、行政や企業からの各種証明書を管理するサービスのテストプロジェクトに、リスクベースドテストを取り入れた際の事例です。（図参照）
リスク管理表と実際の不具合検出を比較すると傾向はほぼ一致しており、重要度高(RED)のエリアから55%の不具合が検出されました。ただし、重要度中（YELLOW）からも欠陥検出率が高かった機能がありました。このように、傾向をデータとして収集することも、リスクベースドテストを適用すべきプロジェクトを見極める第一歩になります。
まとめ
事例紹介では、事前のリスク評価・分析と実際の傾向が一致した事例をご紹介しましたが、傾向が一致しなかったプロジェクトもあります。組織内でデータを収集して、どういったテスト対象には適用可能なのかを把握していくことが大切でしょう。まずは難しいことは考えずにやってみよう！という気持ちで、最初のステップである「リスクの洗い出し」から取り組んでみましょう。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。
