JSTQB Advanced Level シラバス(テストマネージャー)を読む その６．テストマネジメント編②
こんちは。一人民族大移動 ふっくら太郎です。
2017年8月26日(土曜)に実施されるJSTQB AdvancedLevel試験 テストマネージャー受験に向け、短期集中で、JSTQB Advanced Level シラバス(テストマネージャー)についての記事を上げていきたいと思います。
今回は、「テストマネージメント」の「2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ」を読み解きたいと思います。
[JSTQB AdvancedLevel テストマネージャー シラバス]
・ISTQBテスト技術者資格制度
Advanced Level シラバス 日本語版 テストマネージャ Version2012.J03
http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf
2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ
2.3.1 リスクベースドテスト
- リスクベースドテストで扱うリスクの種類
・プロダクトリスク
→潜在的な問題の主な影響がプロダクト品質に及ぶもの。
・プロジェクトリスク、計画リスク
→潜在的な問題の主な影響がプロジェクトの成功に及ぶもの。
- テストの目的
・品質リスクレベルを受け入れ可能なレベルにまで下げること。
- テストの内容
・ユーザ、ステークホルダの品質満足度に影響する要因 (機能性に関する問題、
性能やユーザービリティなど非機能性に関する問題)をもとに、テスト条件化し
て、テスト設計・実装・実行して、リスクを軽減する。
・プロダクト品質リスクをもとに、テスト工数の割当、テストケースの作成、重
要度を決定する。
- リスク軽減の判定方法
・テストで欠陥が抽出された場合。
→リリース前に欠陥が除去されたため、品質リスクが軽減されたと判断。
・テストで欠陥が抽出されなかった場合。
→テスト条件下でテスト対象が正常に動作したことにより、品質リスクが軽減
されたと判断。
- リスクベースドテストで行う活動。
・リスク識別
・リスク軽減
・リスクマネージメント
- リスクベースドテストの効果を高めるために必要なこと。
・「リスク識別」と「リスクアセスメント」で発見された欠陥、故障による品質
リスクを専門的に評価するため、テスト担当者が積極的に関与する。
2.3.1.1 リスク識別
- ステークホルダが用いるリスク識別に必要な技法。(１つ、または複数組み合わせて使用する)
・専門家へのインタビュー
・第三者によるアセスメント
・リスクテンプレートの使用
・プロジェクトの振り返り
・リスクに関するワークショップ
・チェックリストの活用
・過去の経験の活用
- リスク識別でステークホルダのサンプルを多く取り込むことにより、重要な品質リスクを数多く検出できる。
- リスク識別で検出されるプロダクトリスク以外のリスク。
・要求仕様や設計仕様に関するドキュメントの問題。
・プロジェクトリスク。
2.3.1.2 リスクアセスメント
- 活動内容
・リスクを分類し、リスク発生の可能性、影響を調査する。
- リスクの分類方法
・ISO9126の品質特性や、組織で用意しているチェックリストを利用して、リス
クを性能、信頼性、機能性などの特性別に分ける。
- リスクレベルの決定方法
・リスクアイテムごとに、リスク顕在化の可能性と、影響を評価する。
- プロダクトリスクとプロジェクトリスクが顕在化する要因
・技術およびチームの複雑性
・ビジネスアナリスト、設計者、プログラマの個人的な問題およびチームの問 題。
・チーム内の衝突
・供給者側との契約の問題
・チームの地理的な問題
・レガシーアプローチ対新しいアプローチ
・ツールと技術
・劣悪なマネージメントまた技術的なリーダーシップ
・時間、リソース、予算、およびマネージメントのプレッシャー
・早期からの品詞保証活動の欠如
・高い変更率
・高い初期欠陥率
・インターフェイスと統合の問題
- プロダクトリスクとプロジェクトリスク発生による被害に影響する要因。
・影響を受ける製品特性の使用頻度
・ビジネス目標の達成に対する製品特性の重要度
・イメージの悪化
・業務の損失
・財政的、環境保護的、社会損失または責任の可能性
・民事上、または刑事上の法的拘束
・ライセンスの損失
・妥当な回避策の欠如
・故障の判明による否定的な評判
・安全性
- リスクレベルの評価方法
・「影響度小」、「影響度中」、「影響度大」など、定性的にリスクレベルを決
め、リスクの重要性や優先度などの項目に従い重み付けを行い、数値化する。
数値化したリスクを定量的に管理し、評価する。
・作成したリスクレベルは、リスク軽減のためのガイドラインとして用いられる
ため、プロジェクト内で合意のもと決定する。
- リスク分析方法
・統計的手法を用いてリスクデータを評価する場合を除き、ステークホルダの主
観的な認識に基いて評価する。
2.3.1.3 リスク軽減
- リスクレベルとテスト工数・内容の関係。
・リスクレベルが高いとテスト工数は大きくなり、ペアワイズテストなど、精緻
なテスト技法を使用する。
・リスクレベルが低いとテスト工数は小さくなり、同値分割法や探索的テストな
ど、精緻ではないテスト技法を使用する。
・法律や、安全基準に基づいてテストする場合は、各基準で定義しているテスト
技法やカバレッジを満たさなければならない。
- リスクレベルに影響する要素
・プロジェクトの成果物のレビュー適合度合い。
・テスト担当者の経験度合い。
・再テスト、回帰テストの実行度合い。
- プロジェクト期間中に行うこと
・検出した品質レベルの内容に合わせてリスクレベルの再評価、テスト項目を追
加、変更する。
2.3.1.4 ライフサイクルにおけるリスクマネジメント
- リスクマネージメントで求められること。
・開発ライフサイクル全般を通して、適切にテスト計画に組み込まれること。
・重要度の高いリスクを早期に検出できるように、複数のテストレベルでリスク
に関する問題を検出する。
・欠陥の検出だけではなく、原因分析も行い、後段のプロセスで欠陥の埋め込み
を防ぐため、プロセス改善する。
- リスクベースドテストでテストの順番、優先度を決めるために用いられる技法。
・「縦型探索」（depth-first）
→高リスクなテストから順番にテストを実施する。
・「横型探索」（breadth-first）
→リスクレベルに基づいてサンプルを抽出し、すべてのリスクアイテムに対し
て部分的に(サンプル抽出した内容のみ)テストを実施する。
- リスクベースドテスト結果
・テスト結果は、ソフトウェア開発ライフサイクルを通じて、リスク残存度合い
をモニタリング、コントロールするために必要な情報を提供する。
2.3.2 リスクベースドテストの技法
- 非公式なテストアプローチ
・探索的テスト
→メリットは、記述式テストでカバーできないテスト観点を補える。
デメリットは、欠陥の影響よりも、欠陥の潜在性に意識が集中する可能性が
あること、テスト担当者の経験、好みに影響されること。
- 軽量のリスクベースドアプローチ
・メリットは、非公式アプローチの反応の早さや柔軟性と、より公式なアプロー
チの権限や合意形成をあわせ持つ。
主なテスト技法
→実用的リスク分析とマネージメント
→体系的ソフトウェアテスト
→プロダクトリスクマネジメント
・主な特徴
→効率性が時間に比例して向上する。
→初期のリスク識別およびリスクアセスメントにおいて、ビジネス的および技
術的観点を持つステークホルダが広範に関与する。
→プロジェクトのもっとも早い段階で導入した場合、および品質リスクを軽減
するために最大に作用する。
→生成された出力（リスクマトリクスまたはリスク分析テーブル）を、テスト
計画とテスト条件、および後続するすべてのテストマネジメント活動とテス
ト分析活動のためのベースとして使用する。
→すべてのレベルのテストステークホルダにとっての残存リスクが何か、とい
うことが分かるようなテスト結果の報告に役立てることができる。
・テスト技法の使用について
| テスト技法 | 使用に関する注意事項 |
| 実用的リスク分析とマネージメント | リスクベースの戦略と要件ベースの戦略をあわせて使用する。 |
| 体系的ソフトウェアテスト | 要求仕様が提供される場合以外は使用できない。 |
| プロダクトリスクマネジメント | リスクベースの戦略と要件ベースの戦略をあわせて使用する。 |
→テストマネージャは、要件に関連する非機能要件における重要リスクを見逃
さないこと。
- 公式のリスクベースドアプローチで用いるテスト技法
| テスト技法 | 内容 |
| ハザード分析 | システムが引き起こす可能性がある危険な状態を分析する。 |
| エクスポージャーコスト | リスクが発生したときに発生するコストを分析する。 ・故障が発生する確率と発生による損失コスト ・故障に対するテストコスト |
| 故障モード影響解析（FMEA） | 故障・不具合の防止するため、潜在的な故障を分析する。 |
| 品質機能展開（QFD） | 顧客ニーズと設計特性の品質に関する齟齬を分析する。 |
| フォールトツリー解析（FTA） | テストまたは市場で発生した故障、または潜在的な故障（品質リスク）の根本原因を分析する。 |
- リスクベースドテストの入力・プロセス・出力
・入力
→ステークホルダの知識、仕様、および過去のデータ。
・プロセス
→リスク識別、リスクアセスメント、およびリスクコントロール (リスク軽
減、マネージメント)
・出力
→品質リスク。
→仕様などの入力ドキュメントで検出した欠陥。
→リスクアイテムに関連する疑問点や問題。
→プロジェクトリスク。
- ステークホルダの分類
・ビジネスステークホルダ
→ビジネス観点からリスクの識別、発生の可能性を評価できる人。
・テクニカルステークホルダ
→技術的な観点からリスクの識別、発生の可能性を評価できる人。
| ビジネスステークホルダ | テクニカルステークホルダ |
| 顧客 | 開発者 |
| ユーザ | アーキテクト |
| 運用スタッフ | データベース管理者 |
| ヘルプデスクスタッフ | ネットワーク管理者 |
| テクニカルサポートスタッフ | テクニカルサポートスタッフ |
- リスクアイテムの識別方法
・リスクレベルの評価について、テストグループを含むステークホルダ全員が、
共通の評価方法で識別、評価しなければならない。
- リスクベースドテストのテスト終了作業
・リスクベースドテストの成否を次の4つの質問を使って判定する。
→テストチームは、重要度の低い欠陥よりも高い割合で重要度の高い欠陥を検
出したか？
→テストチームは、テスト実行期間の早期に重要な欠陥のほとんどを検出した
か？
→テストチームは、テスト結果をリスクの観点でステークホルダに説明できた
か？
→テストチームによりスキップしたテストがあった場合、そのテストは実行し
たテストよりも関連するリスクのレベルが低かったか？
2.3.3 テストを選択するためのその他の技法
- 要件ベースドテスト
・要件の欠陥チェックリストを使用して、要件の曖昧性を識別し除去する。
・要求仕様が曖昧、検証不能、不完全、または存在しない場合、機能しない。
→その場合、ユースケース、ユーザ（ペルソナとも呼ばれる）、入力、および
出力を組み合わせて活用するというモデルベースのアプローチを使用する。
- 方法論的アプローチ
・チェックリスト等を利用して、テスト範囲、テスト量、テスト工数を決定す
る。テスト対象の変更量が少ない場合は、有効だが、変更量が多いと機能しな
いことがある。
- 対処的アプローチ
・テストの分析作業、設計作業、または実装作業を殆ど行わず、テスト対象の欠
陥の偏在を検出する。他の技法と合わせて使用する。
2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て
- 開発モデル別テストの優先度付けと工数の割り当て方法
| 開発モデル | 方法 |
| シーケンシャルライフサイクル | 要件フェーズでテストの選択とテスト工数の割り当てを行い、最初にテス トの優先度付けを行う。 |
| イテレーティブライフサイクルまたはアジャイルライフサイクル | イテレーションごとのアプローチ。 |
- 結果レポートおよび終了基準評価
・テストレポートでは、実現された利点と実現されていない利点の他、対応済み
のリスクと未対応のリスクを掲載する必要がある。
まとめ
- 品質リスクレベルを受け入れ可能なレベルに軽減するため、リスクベースドテストを実施して、プロダクトリスクを軽減する。
- リスクベースドテストでは以下の4つの活動を行う。
・リスク識別
・リスク軽減
・リスクマネージメント
- リスクベースドテストは、非公式な技法から公式的な技法まで、様々な技法を用いて行う。場合によっては、技法を組み合わせてリスク評価する。
