リスクベースドテストを活用しよう

1. リスクベースドテストを活用しよう ver2013/12/13 WACATE2013冬井芹　洋輝 1

2. 自己紹介 •  井芹　洋輝 –  組み込み開発・テストのコンサル・エンジニア –  これまで医療機器、自動車などのソフトウェア開発に従事 –  「Androidアプリテスト技法」「ソフトウェアテスト総集編」など執筆 –  その他テストを中心に講演や執筆、研究発表を行っている 2

3. 講演概要 •  このセッションはリスクベースドテストの講義になります –  その基礎として、リスク分析やリスクマネジメントにも触れていきます 3

4. 講演概要 •  目的 –  以下についての一連の流れのイメージを具体的に持っていただくことを目的としています •  リスクに基づいたテストの構築 •  テスト設計において、リスクを加味してテストを改善 –  また、リスクベースドテストは誤った運用でまずいテストを行う事例が珍しくありません。防止するための注意点などを、イメージを固めた上で提示します •  対象 –  業種を問わず、テスト設計をする人 4

5. アウトライン 1.  2.  3.  4.  5.  基本用語の解説リスクマネジメントプロセスの進め方リスクベースドテストの進め方リスクベースドテストの限界・注意点まとめ 5

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

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

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

54. その他アクティビティ •  リスクコントロール –  リスクレベルを許容可能なレベルまで軽減する •  残存リスクの評価 –  リスクコントロール結果のリスクレベルを評価し、対応を検討する。安定したフレームワークを使う設計改善で信頼性を高める発生確率頻繁にしばしばほとんどない大 III III II 重大度中 II II I 小 II I I 価格設定を下げる課金をやめる 54

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

90. リスクベースドテストの限界・注意点 •  リスクベースドテストは様々な領域で活用できる基礎的なアプローチですが、万能ではありません •  不適切な運用によって、問題あるテストを行ってしまう事例が少なくありません。 •  この章では、不適切な運用を避けるための注意点やリスクベースドテストの限界について解説します 90

91. リスクは本来定量化・合理的扱いが困難数字と実態との乖離を認識しよう •  リスクやリスクマネジメントは定量管理が困難 –  発生確率やリスクレベルは一つの値に定めるのが難しい。様々なリスクを単一指標で管理するのも難しい。 –  ソフトウェアの許容レベルが妥当なのか、リスクコントロールが妥当なのかの判断は基本的に困難 •  「飛行機と自動車どちらが安全か？」 •  リスクベースドアプローチでは形式的に定量化している。本質や実態とかい離している場合がある •  リスクレベルを絶対視しない。リスクに基づいたテストだけに頼らない 91

92. リスクコントロールを優先すると無難な開発になる視野を広く持ってリスク管理しよう •  リスクコントロールの効率重視の開発を行うと、リスクの源を除く方向性を向く –  安全だが枯れた技術で構成された平凡な製品となる •  それがよい場合もあればよくない場合もある •  リスク管理を行う上では視野を広く持とう –  リスク管理の視野を広げよう •  プロダクト・プロジェクトでなく、ビジネスリスクも考慮しよう •  ネガティブリスクだけでなく、ポジティブリスクも考慮しよう –  リスク以外の視点も持とう •  KPIの定義、こだわり •  新しいものや変化したものを生み出すためには、リスク管理はかえって邪魔なことがある 92

93. リスクは変化する継続的に管理しよう/蓄積できるものを見極めよう •  リスクやリスクレベルは時間とともに変化する •  適切なリスクコントロール手段も時間とともに変化する –  厳格にリスク分析しても時間経過で陳腐化する •  変化するものと蓄積できるものを見極める変化するものは継続的に管理し、蓄積できるものは蓄積する –  変化するもの：リスクやリスクコントロール •  厳格化するより継続して管理することが大事 –  蓄積できるもの：分析観点、過去の統計 •  資産として蓄積し、リスク管理をよりやりやすくするのが大事 –  不具合モード、ハザード観点、危害リスト、チェックリスト –  データの分析・整理 93

94. テストによるリスクコントロールにはプロセスのV&Vが必要 •  リスクから適切なテストを構築しても、それが適切に運用されなければ意味が無い –  「テストはちゃんと遂行されるもの」という前提は、手戻り時のテストや工数逼迫時にしばしば崩れる •  テストによるリスクコントロールには、テストプロセスやその実施状況の検証・妥当性確認が必要 –  テストでリスクを軽減するならば、適切なテストが設計・実施されているか、実施されたテストは目的を達成するものか、チェックする仕組みを作ろう 94

95. リスクベースドアプローチは受動的全体整合の確保や全体網羅が苦手 •  リスクベースドテストは危害・リスク・問題・事象ドリブン –  全体整合を取りつつ、品質を保証したり目的を達成したりするのが苦手 –  すべてのリスクや問題を抽出するのは困難。網羅的なテストの構築は非効率 •  体系的なＱＡやテストのアプローチを主軸にし、リスクベースドテストはその補強策として活用しよう •  あるいはリスクやリスクコントロールの全体整合性を確保する仕組みを取り入れよう 95

96. リスクアセスメントのゴールの一つはコンセンサスの形成 •  リスクアセスメントでは、様々な識者から網羅的にリスクをピックアップし、リスクコントロール手段についてステークホルダ間で同意をとるのが大事 •  手法や技法にこだわる前に、いろいろな関係者からリスクを引き出し、それらの対策を関係者で同意をとる仕組み作りを重視しよう 96

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

リスクベースドテストを活用しよう

You are reading a preview.

リスクベースドテストを活用しよう

More Related Content

Viewers also liked

More from H Iseri

Featured

Related Books

Related Audiobooks