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