リスクベースドテストを活用しよう/Risk Based Testing In Action

Transcript

1. リスクベースドテストを活用しよう ver2013/12/13改訂 WACATE2013冬 井芹 洋輝 1
2. 自己紹介 • 井芹 洋輝 – 組み込み開発・テストのコンサル・エンジニア – これまで医療機器、自動車などのソフトウェア開発に従事 – 「Androidアプリテスト技法」「ソフトウェアテストPRESS総集 編」など執筆 2
3. 講演概要 • リスクベースドテストの入門解説になります – その基礎として、リスク分析やリスクマネジ メントにも触れていきます 3
4. 講演概要 • 目的 – リスクベースドテストについての一連の流れのイ メージを具体的に持っていただくことを目的として います – 次に、リスクベースドテストはまずい運用を行う事 例が珍しくありません。それを防止するための注 意点を解説します • 対象 – 業種を問わず、テスト設計をする人 4
5. アウトライン 1. 基本用語の解説 2. リスクマネジメントプロセスの進め方 3. リスクベースドテストの進め方 4. リスクベースドテストの限界・注意点 5. まとめ 5
6. アウトライン 1. 基本用語の解説 2. リスクマネジメントプロセスの進め方 3. リスクベースドテストの進め方 4. リスクベースドテストの限界・注意点 5. まとめ 6
7. リスクとは • SQuBOK第一版v2012125より抜粋 – 『危害の発生確率及びその危害の重大さの組み合わせ』 〔ISO/IEC Guide51:1999〕 – 『事象の発生確率と事象の結果の組み合わせ』〔ISO/IEC Guide73:2002〕 – 『想定された危険な兆候の生起確率と,その生起によって 起こり得る不利な結末との関数』〔ISO/IEC 15026:1998 〕 • 広い意味を持つ言葉 • 今回は明記がない場合、次の定義に従います： 「リスクとは、将来コントロールが必要な事象の発生確率と 重大度を組み合わせて評価したもの」 7
8. 「リスク」が指し示すもの • 単に「リスク」といった場合の対象 – FDA 510(k) • 主に人体への危害のリスク – MIL-STD-882 • 身体障害、環境影響、経済損失のリスク – PMBOK • ネガティブリスク、ポジティブリスクを含む • 「リスク」の種類 – さまざまある – ビジネスリスク • ビジネスの成否にかかわるリスク – プロジェクトリスク • プロジェクトのマネジメントについてのリスク – プロダクトリスク • 製品品質についてのリスク 8
9. リスクの用語 • 危害 – 人や環境などが受ける被害 • 事象（ハザード状態、危険状態） – 危害を発生させる状態 • 事象の源（ハザード、危害要因） – 危害の源となるもの 9 事象の源 事象 危害 起動処理のバグ 起動しない 機能を使えず不快感を 感じる 不正ログインを可能に するセキュルティホール 不正ログインによる データの不正閲覧 個人情報の流出
10. 欠陥 エラー リスクの概念構成 10 事象の源 （ハザード 等） 事象 （ハザード状態等） 危害 （事象の影響） バグでリスクが発生する場合 リスクは事象の 発生確率と重大度の 組み合わせ 例：発火による ユーザの火傷 例：ヒータの発火・炎上 例：許容温度を超過させるヒータの異常制御 例：プログラミングミス 例：ヒータ制御モジュールのバグ ユーザにさらされる 組み合わせた総合評価：リスクレベル
11. リスクの概念構成 ミニワーク • 以下が「事象の源（ハザード）」「事象」「危害 （事象の影響）」のどれに該当するか考えてみ ましょう – 「使い勝手が悪い」 – 「メモリを破壊するバグ」 – 「セキュリティホールによる個人情報の不正公開」 11
12. リスクの概念構成 ミニワーク • 以下が「事象の源（ハザード）」「事象」「危害 （事象の影響）」のどれに該当するか考えてみ ましょう – 「使い勝手が悪い」 • 危害 – 「メモリを破壊するバグ」 • 事象の源 – 「セキュリティホールによる個人情報の不正公開」 • 事象 12
13. リスクマネジメントとは • リスクマネジメントとは – JSTQB ソフトウェアテスト標準用語集（Version 2.1.J01) • 「リスクの識別、分析、優先順位付け、コントロールのタスクに手 順や実施方法を体系的に適用すること」 • 広い意味を持つ言葉 • 今回は明記がない場合、上記JSTQBの定義に従い ます 13
14. リスクベースドテストとは • SQuBOK第一版v2012125 – 「リスクに基づいた技法とは、リスク分析に基づい てテストを設計する技法であり、リスクベースドテ ストと呼ばれることが多い。リスクのとらえ方によ り次の２種類の技法に分かれる。 – (1)プログラムの機能や特性ごとに問題が発生す る可能性と影響度を「品質リスク」として整理し、 それに基づいてテストを計画、実行するテストマ ネジメントの技法 (2)プログラムが障害を起こしそうな状況（リスク） の分析に基づいてテストを設計する技法」 14
15. リスクベースドテストとは • 次の２つのアプローチのどちらかを指します – リスクをコントロールする手段としてテストを作成・ 実施する – 対象のリスクに応じて、テストの十分性基準や優 先順位を調整する 15
16. アウトライン 1. 基本用語の解説 2. リスクマネジメントプロセスの進め方 3. リスクベースドテストの進め方 4. リスクベースドテストの限界・注意点 5. まとめ 16
17. リスクマネジメントプロセス • リスクマネジメントプロセスとは – リスクを識別・分析・コントロールするためのプロ セス – リスクコントロール手段としてのリスクベースドテ ストの基礎になります – 様々な解説がありますが、今回は一般的なプロ セスの一つを紹介します 17
18. リスクマネジメントプロセス 一般的なフロー 1. 事前分析 – 適切にリスク分析を行えるように、観点や対象を分 析します 2. リスクの識別 – 対応が必要なリスクを洗い出します 3. リスクアセスメント – 識別したリスクを分析し、リスクレベルを評価します 4. リスク・コントロール – リスクを目標レベルまで軽減します 5. コントロール後のリスクの評価・フォロー – リスク・コントロールの評価やフォローを行います 18
19. リスクマネジメントプロセスの運用 • 開発進展にともなってリスクや妥当なリスクコント ロール手段はどんどん変化します • リスクマネジメントプロセスは開発プロセスと並行し て、継続的に反復して運用されます 19 要求定義 設計 実装 テスト 開発プロセス 識別 アセスメ ント リスクコン トロール 評価・ フォロー リスクマネジメントプロセス 継続的にリスクを監視 継続的にリスクを管理
20. リスクマネジメントプロセスを 構成するアクティビティ 1. 事前分析 2. リスクの識別 3. リスクアセスメント 4. リスク・コントロール 5. 残存リスクの評価・フォロー 20
21. 1.事前分析 • 適切にリスク分析を行えるように、目的や対 象、観点を分析します – 主な分析対象 • ステークホルダ、意図される用途 • 各種基準 – 重大度、発生確率、リスクレベル • 分析に有用な観点 – 想定される危害、リスクタイプ、ハザードタイプ、不具合モード、 典型的な危害シナリオ 21
22. 1.事前分析 各種基準や定義を明確化する • リスク分析対象が誰のためにどのような用途 （Intended Use）で使用されるか明確化します – ステークホルダや用途によって許容できるリスク レベルが変化します。またリスクは複雑・膨大で す – Intended Useを明確にして、リスクマネジメントの スコープおよび判断基準を具体化します 22
23. 1.事前分析 各種基準や定義を明確化する • リスク管理の目的に基づいて、リスクレベル評価 基準を明確化します – 重大度の例： • Catastrophic – 死亡、回復不能な重大な障害・環境影響、1000万ドル以上の経 済損失 • Critical – 永続的な部分的障害・環境影響、100万ドルから1000万ドル未 満 • Marginal – 回復可能な障害や環境影響。10万ドル以上から100万ドル以下 の経済損失 • Negligible – 一日以内に復帰可能な怪我や環境影響。10万ドル未満の経済 損失 » MIL-STD-882(Department of Defence Standard Practice:System Safety) 23
24. 1.事前分析 各種基準や定義を明確化する • リスク管理の目的に基づいて、リスクレベル 評価基準を明確化します – 重大度の例： • 3 – プロジェクトを1ヶ月以上遅延させる。あるいはプロジェクトを 失敗させる • 2 – プロジェクトを一週間以上遅延させる • 1 – プロジェクトを1日程度遅延させる • 0 – 遅延なく対応可能である 24
25. 1.事前分析 各種基準や定義を明確化する • リスク管理の目的に基づいて、リスクレベル 評価基準を明確化します – 発生確率の例： 25 選択肢 確率ベース 使用回数当たりの障害発生率 台数ベース 生産台数当たりの障害発生率 Frequent 1 1/10 Probable 1/10 1/100 Occasinal 1/100 1/1000 Improbable 1/1000 1/10000
26. 1.事前分析 観点の分析：危害の分析 • 想定される危害を事前に定義するとリスク分 析が用意になります – 電気ポッドの例 26 危害 重大度 感電 Critical 熱湯による火傷 Critical 水への有毒物質の流出 Critical 有毒ガスの発生 Critical 加熱できない Marginal 保温できない Negligible
27. リスクマネジメントプロセス 各詳細 1. 事前分析 2. リスクの識別 3. リスクアセスメント 4. リスク・コントロール 5. 残存リスクの評価・フォロー 27
28. 2.リスクの識別 • 分析・コントロールが必要なリスクを洗い出し、 その特性を調査します 28
29. 2.リスクの識別 • 担当 – ブレスト、インタビュー、アンケート、専門家による 分析、外部資産の活用 • 情報源 – 過去・類似プロジェクトの知見、対象の分析結果、 標準や規格 • 手法 – KJ法、ガイドワードの活用（HAZOP等）、各種レ ビュー手法、リスク観点（リスクタイプや故障モー ド等）の活用、マインドマップ、チェックリスト、リス クブレークダウンストラクチャ、課題ばらし 29
30. 2.リスクの識別 リスクの識別のアプローチ • 方向性 – 順方向探索 – 逆方向探索 – トップダウン探索 – ボトムアップ探索 • 観点の例： – カテゴライズ：リスクタイプ、ハザード観点、危害観点、 故障モード – ガイドワード：意地悪漢字、HAZOP • 今回は「要素分解によるボトムアップ分析」を解 説します 30
31. 1.リスクの識別：手法の例１ 要素分解によるボトムアップ分析 • 手順 1. リスク分析対象を構造や機能、プロセスを観点に 構成要素に分解します。 2. 各要素ごとに、ハザードや危害シナリオ（ハザード が発生し、危害が生じるシナリオやストーリ）がない か分析します 3. ピックアップした危害シナリオをリスクとして展開し ます • この手法について – FMEAでしばしば行われます – リスク分析だけでなく、ミスユースケースの検出や 設計評価にも有効な手法です 31
32. 1.リスクの識別：手法の例１ 要素分解によるボトムアップ分析 1. リスク分析対象を構造や機能、プロセスなどの構 成要素に分解します。 – 例）ガチャ機能 – ボタンを押すと300円分の電子マネーを消費してアイテムを出力する – 出力アイテムは、事前設定された確率に従って複数から１つ選ばれる 32 ユーザ GUI フレームワーク アプリケーション ネットワーク モジュール スマートフォンOS ゲーム サーバ 1.タッチ操作 2.タッチイベント通知 3.ガチャ開始 4.ガチャ開始 5.アイテムデータ通知 6.アイテムデータ通知
33. 事前分析したハザード観点 ・ゲームサーバとの断線 ・GUIフレームワークのフ リーズ ・・・ 1.リスクの識別：手法の例1 要素分解によるボトムアップ分析 2. 各要素ごとに、危害を発生させるシナリオがないか、 分析観点を活用して分析します 33 ユーザ GUI フレームワーク アプリケーション ネットワーク モジュール スマートフォンOS ゲーム サーバ 1.タッチ操作 2.タッチイベント通知 3.ガチャ開始 4.ガチャ開始 5.アイテムデータ通知 6.アイテムデータ通知 事前分析した危害リスト ・不正なガチャ実行 ・ガチャを実行できない ・・・
34. 1.リスクの識別：手法の例1 要素分解によるボトムアップ分析 3. 対応すべき危害シナリオをピックアップします 危害シナリオ：事象から危害が発生するシナリオやユースケース 34 事前分析したハザード観点 ・ゲームサーバとの断線 ・GUIフレームワークのフ リーズ ・・・ ユーザ GUI フレームワーク アプリケーション ネットワーク モジュール スマートフォンOS ゲーム サーバ 1.タッチ操作 2.タッチイベント通知 3.ガチャ開始 4.ガチャ開始 5.アイテムデータ通知 6.アイテムデータ通知 事前分析した危害リスト ・不正なガチャ実行 ・ガチャを実行できない ・・・ サーバの負荷 増大でガチャを 実行できない 通信の偽装 で不正にガ チャ実行
35. 1.リスクの識別：手法の例1 要素分解によるボトムアップ分析 3. 対応すべき危害シナリオをピックアップします 危害シナリオ：事象から危害が発生するシナリオやユースケース 35 ユーザ GUI フレームワーク アプリケーション ネットワーク モジュール スマートフォンOS ゲーム サーバ 1.タッチ操作 2.タッチイベント通知 3.ガチャ開始 4.ガチャ開始 5.アイテムデータ通知 6.アイテムデータ通知 分析にはマインドマップのようなツリー分析も有効です
36. 1.リスクの識別：手法の例1 要素分解によるボトムアップ分析 4. 危害シナリオをリスクに展開します 36 サーバの負荷 増大でガチャを 実行できない 通信の偽装 で不正にガ チャ実行 事象の源 事象 危害 偽装通信を行う不 正改造アプリ ガチャ実行通信の 偽装送信 不正なガチャ実行 ゲームサーバ過 負荷 ガチャ実行通信不 能 操作してもガチャ を実行できない
37. 1.リスクの識別：手法の例2 リスクタイプによる分析 1. リスクの種類をリストアップします – リスクタイプの例 • 機能性リスク • 信頼性リスク • 保守性リスク • … 2. リスクタイプに基づいて品質ごとのリスクレベル や危害シナリオを考えていきます • この手法について – リスクのタイプのリストに基づいてリスクを抽出します – リスクベースドテストの解説でよく扱われます 37
38. 1.リスクの識別：手法の例2 リスクタイプによる分析 機能性リ スク 信頼性リ スク … 対象１ ◦ 対象２ 対象３ … 38 対象１の信頼性 が☓☓により低 下する リスクタイプ 対象 対象項目ごとにリスクタイプを観点にして分析します
39. リスクマネジメントプロセス 各詳細 1. 事前分析 2. リスクの識別 3. リスクアセスメント 4. リスク・コントロール 5. 残存リスクの評価 39
40. 2.リスクアセスメント • 識別したリスクを分析・評価します – リスクの整理や粒度調整を行います – リスクの重大度、発生確率を評価し、リスクレベ ルを評価します – 評価結果に応じて優先度付けや全体の対応方 針を作成します – 手法 • リスク分析 – FMEA/FTAといった手法、規格といった体系に基づいて分析 • リスクレベルの設定 – 掛け算方式、足し算方式、リスクマトリクス法、R-MAP法 40
41. 2.リスクアセスメント リスクの重大度・発生頻度の定め方の例 1. リスクに紐付く危害から重大度を定めます 2. 危害シナリオや事象の発生確率を選択します – 発生確率は過去データ、類似データ、専門家によるアセスメント、KKD等で評価 41 感電 ：Critical 熱湯による火傷 ：Critical 融解による有毒物質の流出 ：Critical 融解による有毒ガスの発生 ：Critical 加熱できない ：Negligible 保温できない ：Negligible ポンプ制御のバ グで湯が無操作 で出力されて ユーザが火傷 2.あとはこのシナリオがどれぐらいの確率 で発生するかを、過去のデータや標準を 使って選択する 90%発生する ：3 10%発生する可能性がある ：2 ほぼない ：1 1. 事前分析で作成した危害と重大度のリ スクとから重大度を選択
42. ワーク リスクの識別・アセスメントを行おう 42
43. ワーク リスクの識別・アセスメントを行おう （題材） • 【分析対象】スマートフォンゲームのガチャ機能 – インターフェース • インプット：電子マネー、ガチャ開始ボタン • アウトプット：アイテム – ボタンを押すと300円分の電子マネーを消費してアイテムを出力する – 出力アイテムは、事前設定された確率に従って複数から１つ選ばれる – 非認可だがアイテムはオークションで現金と変換可能な仕組みができている 43 ユーザ GUI フレームワーク アプリケーション ネットワーク モジュール スマートフォンOS ゲーム サーバ 1.タッチ操作 2.タッチイベント通知 3.ガチャ開始 4.ガチャ開始 5.アイテムデータ通知 6.アイテムデータ通知 リスク分析対象
44. ワーク リスクの識別・アセスメントを行おう （課題内容） • ワーク内容 1. 危害の重大度、発生確率のリストを定義してください 2. 危害をリストアップしてください（2つ程度） 3. 危害シナリオを考えてください(2つ程度) 4. 危害シナリオからリスク管理表を作成してください 5. リスクに重大度・発生確率を割り当ててください 44 事象の源 事象 危害 重大度 発生確率 ゲームサーバ の過負荷 ゲームサーバと 通信不能 ガチャ開始操作をしても ガチャを実行できない 3 しばしば 作成するリスク管理表
45. ワーク リスクの識別・アセスメントを行おう （課題内容） • ワーク内容（ヒント） 1. 危害の重大度、発生確率のリストを定義してください 45 • 危害の重大度の例 – 3：ユーザに1000円以上の被害 あるいはユーザが脱会 – 2：ユーザに1000円未満の被害 あるいは補償がなければユーザが脱会 – 1：ユーザに金銭的被害がない あるいは不快感が許容可能 • 発生確率の例 – 3：必ず発生する – 2：発生する可能性が高い – 1：発生する可能性が低い
46. ワーク リスクの識別・アセスメントを行おう （課題内容） • ワーク内容（ヒント） 2. 危害をリストアップしてください 46 危害 重大度 過剰な課金（過剰分：1000円未満） 2 過剰な課金（過剰分：1000円以上） 3 ユーザが意図しないガチャ開始 2 操作してもガチャを開始できない[ 1
47. ワーク リスクの識別・アセスメントを行おう （課題内容） • ワーク内容（ヒント） – 3. 危害シナリオを考えてください（2個程度） 47 • ユーザが操作ミスでガチャ開始SWを押す。 それによりユーザの意図と反してガチャが開始され、ユー ザは不快感を感じる • ユーザがガチャ開始SWを押す。そこでアプリがバグにより ゲームサーバからのアイテムデータの受信を無視する。結 果、ユーザは電子マネーを消費してアイテムを取得できな い
48. 2.リスクアセスメント リスクレベルの設定 • 重大度、発生確率に基づいて総合的なリスクの指 標を求めます – 手法：足し算式、掛け算式、リスクマトリックス、R-MAP等 • 定め方の例：リスクマトリックスの使用 – 重大度×発生確率の表を作成。表中にリスクレベルを記 述します – 重大度と発生確率の交点をリスクレベルとします 48
49. 2.リスクアセスメント リスクレベルの設定 • 定め方の例：リスクマトリックス – 重大度×発生確率の表を作成。表中にリスクレベルを記述します – 独自の重大度や発生確率に柔軟に対応できます 49 頻繁に しばしば ほとんどない 大 III III II 中 II II I 小 II I I 重大度 発生確率 •リスクレベルの例 III：軽減が必要。II以下に軽減すること II：軽減が必要。ただし所定のレビュー で問題がないと判断された場合、軽減 しなくて良い I：許容できる。軽減は不要
50. ワーク リスクレベルを割り当てよう 50
51. ワーク リスクレベルを割り当てよう • （前回の続き） • ワーク内容 – リスクレベルの定義とリスクマトリクスを作成しよう – リスクマトリクスに基づいてリスクレベルを設定しよう。結 果はリスク管理表に記述しよう 51 事象の源 事象 危害 重大度 発生確率 リスクレベ ル ゲームサー バの過負荷 ゲームサー バと通信不 能 ガチャ開始操作をし てもガチャを実行でき ない 3 しばしば II
52. リスクマネジメントプロセス 各詳細 1. 事前分析 2. リスクの識別 3. リスクアセスメント 4. リスク・コントロール 5. 残存リスクの評価・フォロー 52
53. その他アクティビティ • リスクコントロール – リスクレベルを許容可能なレベルまで軽減する • 残存リスクの評価・フォロー – リスクコントロール結果のリスクレベルを評価し、対応を 検討する 53 頻繁に しばしば ほとんどない 大 III III II 中 II II I 小 II I I 重大度 発生確率 信頼性を高める 要件の調整、機能ドロップ等で リスク要因を削減する
54. アウトライン 1. 基本用語の解説 2. リスクマネジメントプロセスの進め方 3. リスクベースドテストの進め方 4. リスクベースドテストの限界・注意点 5. まとめ 54
55. リスクベースドテストとは（復習） • 次の２つのアプローチのどちらかを指します – リスクをコントロールする手段としてテストを作成・ 実施する – 対象のリスクに応じて、テストの十分性基準や優 先順位を調整する 55
56. リスクベースドテストの目的 • 以下のどちらかが主な目的です – 対象の品質リスクを目標レベルまで軽減する • テストでリスク事象の発生確率が一定以下であること を確認する – 品質リスクに応じて、テストの十分性基準や優先 順位付けを調整し、以下を実現する • ハイリスク事象に対するテストを厚くする • テストのリソースやスケジュールに合わせてテストを トリアージする（※このアプローチは批判多い） 56
57. リスクベースドテストは 様々な運用形態がある • テスト担当者レベル： – 担当者が怪しいと感じたリスクを整理し、それに 基づいてテスト • テストチームレベル： – テスト設計に特化して、チームとしてリスクマネジ メント実施 • チームレベル： – プロジェクト全体のリスクアセスメント・リスクマネ ジメントを実施。 その中でリスクコントロール手段として求められ たテストを作成 57
58. 今回扱うリスクベースドテストのアプローチ • 今回は以下の２つを扱います – テスト設計に特化したリスクベースドテスト • テスト設計のためにリスクを分析 • リスクに応じて、テスト設計を調整 – プロジェクトのリスクマネジメントの一部としてのリ スクベースドテスト • 開発プロジェクトでのリスクマネジメントを実施 • リスクマネジメントの一部としてテストを活用する 58
59. テスト設計に特化した リスクベースドテスト 59
60. テスト設計に特化した リスクベースドテストとは？ • SQuBOK第一版v2012125 – (1)プログラムの機能や特性ごとに問題が発生す る可能性と影響度を「品質リスク」として整理し、 それに基づいてテストを計画、実行するテストマ ネジメントの技法 (2)プログラムが障害を起こしそうな状況（リスク） の分析に基づいてテストを設計する技法 60
61. リスクベースドテストの進め方 1. リスクの識別 2. リスクアセスメント 3. リスクに基づいてテストを構築する 61
62. テスト設計のどこでリスクを活用するか • リスクに基づいて調整する対象 – テストの網羅度、追加テスト • リスクレベルに応じて網羅度を上げる • リスクコントロールとしてのテストの穴を埋める – テストスコープ • リスクレベルに応じてテスト対象・非対象を切り分ける – テストの優先順 • リスクレベルに応じてテストの優先順位を設定する – テスト分析の詳細度 • リスクレベルに応じて、テスト観点の詳細度やテスト分 析のリソースを調整する 62
63. リスクベースドテスト：アプローチの例１ 対象のリスクレベルに応じてテストを調整 • テスト対象を要素分解 – 例：機能ごと、ユースケースごと、コンポーネントごと 63 機能名 沸騰機能 保温機能 出湯機能 電源機能 … テスト対象の 構成要素 ・テスト対象のバグの可能性とバグが あった時の重大度を評価
64. リスクベースドテスト：アプローチの例１ 対象のリスクレベルに応じてテストを調整 • 構成要素ごとにバグが発生した時の最大リス クを分析する • リスクレベルに応じてテスト設計を調整する 64 機能名 重大度 発生確率 リスクレベル テスト設計方針の例 沸騰機能 B ほとんどない II 代表パターンでテストする 保温機能 B しばしば II 代表パターンでテストする 出湯機能 A ほとんどない III 網羅的にテストする … リスクレベル テスト設計方針の例 VI ユーザが操作し得る全パターンをテストする III 有則を網羅する II 代表的なパターンをテストする I テスト対象外として良い
65. リスクベースドテスト：アプローチの例2 リスク事象に対してテストを作成する • リスク事象や危害シナリオをリスク分析する • リスク事象や危害シナリオに対し、それが発 生しないことを確認するテストを確保する 65 例：危害シナリオを分析する
66. • リスク事象や危害シナリオをリスク分析する • リスク事象や危害シナリオに対し、それが発 生しないことを確認するテストを確保する リスクベースドテスト：アプローチの例2 リスク事象に対してテストを作成する 66 リスク事象・レベルに応じてテスト設計を考える リスク事象 重大度 発生確率 リスクレベル テスト設計方針 温度生後の オーバーシュー トで異常発熱 B ほとんどない III シミュレータでオーバー シュートを発生させるパ ターンをすべて網羅する … リスクや危害シナリオに対してテストを作る
67. ワーク リスクに基づいたテスト設計方針の設定 67
68. ワーク リスクに基づいたテスト設計方針の設定 • 機能毎に機能テストを設計します • 機能テストの網羅度のために、各ソフトウェア 機能のリスクを評価します 68
69. ワーク リスクに基づいたテスト設計方針の設定 • シンプルポット – 外部インターフェース • 水位メータ、加熱ヒータ、温度表示モニタ、給湯ボタン、給 湯口、水タンク、電源ボタン – 機能リスト • 水温表示 – 水タンクの水温を表示します • 給湯機能 – 給湯ボタンが押されている間、水を出力します • 加熱機能 – 水を目標温度(100%)まで加熱します • 保温機能 – 水を保温温度(90%)に保温します • 水位による加熱制限機能 – 水が空になったら加熱を停止します 69
70. ワーク リスクに基づいたテスト設計方針の設定 • 重大度 – A：死亡、回復不能な身体的損害 – B：回復可能な身体的損害 – C：許容できる • 発生確率 – 適宜設定してください 70
71. ワーク リスクに基づいたテスト設計方針の設定 • 各機能のリスクレベルを作成してください • 各機能のテスト設計方針を作成してください • 手順の進め方の例 1. 危害とその重大度を定義 2. 機能毎に可能性のある危害シナリオを検討。それに基づいてリス クレベルを定め、リスク管理表に記入 3. 各機能ごとに、リスクレベルに応じたテスト設計方針を作成する 71 機能名 重大度 発生確率 リスクレベル テスト設計方針 沸騰機能 B ほとんどない II 代表パターンでテストする 保温機能 B しばしば II 代表パターンでテストする 出湯機能 A ほとんどない III 網羅的にテストする 電源機能 C ほとんどない I テスト対象外とする …
72. 開発ライフサイクルの一部としての リスクベースドテスト 72
73. 開発ライフサイクルにおけるリスクマネジメント でのリスクベースドテスト • ここで扱うもの – テスト設計に限らないリスクマネジメントにおいて、 テストを活用する。 – テスト設計に特化したリスクマネジメントと進め方 や考え方が変化する • リスクの種類が増える • リスクコントロール手段が増える • リスクマネジメントが複雑化する 73
74. リスクの種類が増える リスクコントロール手段が増える • リスクの種類が増える – 非ソフトウェアのリスク • Ex)ファンの経年劣化による冷却機能の低下 – 非開発のリスク • Ex)法規制の強化による機能制限 • リスクコントロール手段も増える – 設計による対策 – 運用による対策 – レビューによる対策 – テストによる対策等々 74
75. リスクの種類が増える リスクコントロール手段が増える • ブレーキシステムのバグによるリスク – 設計による対策 • フォールト・トレラント – ブレーキを２つ搭載。壊れたら補助ブレーキを使う • フォールトレジスタンス – 壊れないようにブレーキを作る（高品質な部品を使う・信頼でき るエンジニアリングを実施する） • フェールセーフ – ブレーキが壊れたら、ブレーキが掛かるように変更する – 運用による対策 • 定期チェックをユーザに義務付け – レビューによる対策 • 対象の設計書に対して厳格なインスペクションを実施 75
76. リスクの種類が増える リスクコントロール手段が増える 76 リスク 事象・危害 問題化 事象化 トリガ 例：リリース遅延リスク 例：想定を超える手戻りの発生 例：リリース遅延
77. リスクの種類が増える リスクコントロール手段が増える 77 リスク 事象・危害 問題化 事象化 トリガ 例：リリース遅延リスク 例：想定を超える手戻りの発生 例：リリース遅延 •事象や危害に対策する •事象や危害に対応できてい るか評価する •トリガが発生していないか監視する •トリガを予防する •問題化に対策する •リスクを軽減する •リスクコントロールの評 価・維持を行う •リスクコントロールの二 次的リスクを監視する
78. リスクマネジメントにおけるテストの役割 • リスク事象の発生確率・発生可能性が一定以 下であることを確認する – 曖昧さ・不確定さのある発生可能性を、低いほう に収束させる →リスクレベルを低いほうに収束させる • リスク評価に必要な情報を収集する – リスクレベルの評価結果、テスト以外のリスクコン トロールの有効性を、テストを通して評価する 78
79. アウトライン 1. 基本用語の解説 2. リスクマネジメントプロセスの進め方 3. リスクベースドテストの進め方 4. リスクベースドテストの限界・注意点 5. まとめ 79
80. リスクベースドテストの限界・注意点 • リスクベースドテストは様々な領域で活用で きる基礎的なアプローチですが、万能ではあ りません • 不適切な運用によって、問題あるテストを 行ってしまう事例が少なくありません。 • この章では、不適切な運用を避けるための注 意点やリスクベースドテストの限界について 解説します 80
81. リスクは本来定量化が困難 数字と実態との乖離を認識しよう • 本来リスクやリスクマネジメントは定量管理が困難 – 発生確率やリスクレベルは一つの値に定めるのが難しい。 様々なリスクを単一指標で管理するのも難しい。 – 開発中でのソフトウェアの許容レベルが妥当なのか、リス クコントロールが妥当なのかの判断は基本的に困難 • リスクベースドアプローチでは形式的に定量化して いる。本質や実態と乖離している場合がある • リスクレベルを絶対視しない。本質を意識する 81
82. テストのトリアージはテスト不足と隣り合わせ 考えなしのリスクベースのトリアージは避けよう • テストが十分かの判断をリスクレベルだけで 考えるのは困難 • 少ないリソース（人・物・金・時間）に合わせて、 リスクレベル順でテストをトリアージするとテ スト不足を発生させる – 頻発しがちな問題であり、リスクベースドテストが 批判される主要ポイント • 本当に必要なテストの十分性基準は、様々な 観点で分析して考えよう 82
83. リスクは不確定さを持つ 継続的に評価してリスク分析の精度を高めよう • リスクは曖昧で流動的であり不確定さを持つ – プロダクトの品質リスクは製品のライフサイクル 終了時点でようやく確定する。 開発中は一部しか垣間見れない • 継続的にリスク情報を収集し、リスク分析の 精度を高めて妥当な分析結果を目指そう – プロトタイピングや反復開発で早期にテストして フィードバックを確保する – 運用時もプロダクトを監視してリスク情報を得る 83
84. テストによるリスクコントロールには プロセスのV&Vが必要 • リスクから適切なテストを構築しても、それが 適切に運用されなければ意味が無い – 作ったテストが十分に実施されるとは限らない • 開発遅延時の工数ひっ迫時 • リリース間際の小さな変更の連発 • テストでリスクコントロールする際は、テスト実 施の検証・妥当性確認が必要 84
85. リスクアセスメントのゴールの一つは コンセンサスの形成 • リスクアセスメントでは、様々な識者から網羅 的にリスクをピックアップし、リスクコントロー ル手段についてステークホルダ間で同意をと るのが大事 • 手法や技法にこだわる前に、いろいろな関係 者からリスクを引き出し、それらの対策を関 係者で同意をとる仕組み作りを重視しよう 85
86. アウトライン 1. 基本用語の解説 2. リスクマネジメントプロセスの進め方 3. リスクベースドテストの進め方 4. リスクベースドテストの限界・注意点 5. まとめ 86
87. リスクベースドテストを学ぶための 参考文献 87
88. 参考文献 リスクベースドテストについての書籍 • 体系的ソフトウェアテスト入門 • ソフトウェアテスト 12の必勝プロセス – リスクベースドテストについて詳細な解説を行っ ている 88
89. 参考文献 リスクベースドテストについての書籍 • ソフトウェア品質知識体系ガイド – まとまった解説と文献インデックスがある 近々改定予定 89
90. 参考文献 リスクベースドテストについての書籍 • セーフウェア – ソフトウェアのリスク分析について解説が充実している – その他ソフトウェアのリスクマネジメントの解説が充実 – ただしスペースシャトルなど安全性重視の題材が中心 90
91. 参考文献 リスクベースドテストでの手法の解説 • 実践FMEA手法 – FMEAについての解説 – なおFMEA/FTAは様々な本がある。今回は自分が使った本を紹介。他 にも参考になる書籍は様々 91
92. 参考文献 テストのリスクマネジメント • ソフトウェアテスト293の鉄則 – リスクコントロールについてのアドバイスが豊富 92
93. 参考文献 テストのリスクマネジメント • 基本から学ぶテストプロセス管理 – リスクコントロールについてのアドバイスが豊富 – プロジェクトリスクの解説が充実している 93
94. 参考文献 ソフトウェア開発プロジェクトのリスクマネジメント • 熊とワルツを – プロジェクトリスクの管理についての記述が充実 – 読みやすく面白い書籍 94
95. まとめ • このセッションで扱ったもの – リスク/リスクマネジメントプロセス – リスクベースドテスト • テスト設計に特化したリスクベースドテスト • リスクマネジメントでのテストの活用 – リスクベースドテストの問題や注意点 – 明日から使えるリスクベースドテスト – 参考文献 95