JSTQB(ALTM) シラバス学習：2 テストマネジメント(2.3)

2018.04.24更新

2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ

テストマネジメントをする上で、適切なテストを選択して優先度付けすることは永遠の課題となっています。テストマネージャはリスクの識別と分析することにより、以下を定義します。

• 無限にあるテスト条件から、有限の条件セットを選択する。
• 各条件をカバーする適切な工数を決定する。
• 実行するテストの有効性と効率性を最適化する。
• 優先度に基づいて順序付けする。

2.3.1 リスクベースドテスト

リスクには潜在的な問題が顕在化することにより、プロダクト品質に影響する場合とプロジェクトの成功に影響する場合があります。

• 品質リスク、プロダクトリスク、プロダクト品質リスク
• プロジェクトリスク、計画リスク

品質リスクの種類

リスクベースドテストはプロダクト品質リスク分析により品質リスクを識別して評価します。品質リスクはプロダクト内に品質問題が存在する可能性がある状況で、この品質リスクを軽減することが満足度に影響します。

• 正確性：レポートでの不正な計算（機能リスク）
• 効率性：ユーザ入力に対応する応答の遅れ（非機能リスク）
• 使用性：画面の分かりにくさ（非機能リスク）

品質リスクの軽減

以下を行うことでテストで品質リスクを軽減したことを示せます。

• 欠陥が見つかった場合、欠陥を周知させて欠陥に対応する機会を提供する。
• 欠陥が見つからなかった場合、テスト条件の下で正しく動作したことを確認する。

リスクベースドテストの活動

プロダクト品質リスクを使用してテスト条件を選択して、テストケースを作成します。

目的

リスクベースドテストには以下の目的があります。

• プロダクト品質リスクのレベル全体を引き下げる
• リスクレベルを受け入れ可能なレベルまで引き下げる

活動

リスクベースドテストは以下の順序で行います。

最大限の効果を上げるためリスク識別とリスクアセスメントにはステークホルダの代表者を含める必要があります。また、テスト担当者はリスク識別とリスクアセスメントに積極的に関わるる必要がある。

1. リスク識別
2. リスクアセスメント
3. リスク軽減
4. リスクマネジメント

 2.3.1.1 リスク識別

ステークホルダは以下の１つまたは複数の技法を使用してリスク識別を行う。
このサンプルデータを取り込むことは、重要なプロダクト品質リスクの検出に役立ちます。

• 専門家へのインタビュー
• 第三者によるアセスメント
• リスクテンプレートの使用
• プロジェクトの振り返り
• リスクに関するワークショップ
• ブレインストーミング
• チェックリスト
• 過去の経験の活用

また、リスク識別は以下のようなプロダクト品質リスクではない問題（副産物）を生み出します（プロジェクトリスク）。

• 全体的な疑問点または問題の検出
• 仕様書などの参照ドキュメントの問題の検出

2.3.1.2 リスクアセスメント

リスクアセスメントは識別したリスクを分類して、それぞれのリスクに関連する可能性や影響、その他の特性の評価、リスク所有者の割り当てを行います。
リスクの分類はISO9126(ISO25000に改訂)の品質特性を使用することもできるが、多くの組織は他の分類体系を使用しており、リスク識別で使用するチェックリストと同じリスト使用して識別時に一緒に行うことが多い。

リスクレベルの決定

リスク要因の特定

潜在的な問題が顕在化するリスクと顕在化したリスクがステークホルダに及ぼす影響からリスクレベルを決定します。潜在的リスクと顕在的リスクは、以下のようなプロダクトリスク及びプロジェクトリスクに影響する要因があります。

リスクの評価

リスクの可能性（潜在）と影響（顕在）を定量的に確認できれば2つの値から定量的なリスク優先度を計算できますが、通常は定性的（高い、中程度、低いなど）に確認できるリスクが多くあります。
定量的アセスメントが定性的アセスメントよりも優れているかというとそうではなく、それぞれを適切に使い分けることが大切です。また、定性的アセスメントを用いて算出したリスクスコアは定性的かつ相対的な評価点として利用します。

リスクレベルの確立

ステークホルダはそれぞれ異なる見識があるため、リスクレベルには異なる意見を持ち、リスクはステークホルダの主観的な認識から分析されます。そのため、リスク分析では何らかのコンセンサスに達する方法を検討し、リスクレベルを確立させなければなりません。
また、リスクレベルはリスク軽減活動のガイドとして使用するため、リスクの評価点が以下を判断できる結果になっているのかチェックする必要があります。

• テストの順序
• テストの優先度
• 工数の割り当て

2.3.1.3 リスク軽減

リスクベースドテストの目的の一つはリスクの軽減です。プロジェクトの期間中は品質リスクのリスクレベルを変更する追加情報を常に認識しておき、品質リスク分析の調整を定期的に実施する。

リスク分析

• プロダクト品質リスクの識別とアセスメントがテスト計画の基礎となります。
• テスト計画の指定に従いリスクをカバーするようにテストの実装と実行をします。
• テスト開発と実行にかかる工数はリスクレベルに比例します。
• テスト開発と実行にかかる優先度はリスクレベルに基づきます。 

リスクレベルによるテスト技法

リスクレベルに基づく規定

FAA DO-178B/ED 12B、IEC 61508などの安全関連標準でリスクのレベルに基づいたテスト技法やカバレッジの程度を規定しています。

リスクレベルによる影響

以下の決定に影響を与えます。

• プロジェクト成果物のレビュー適用
• 独立性の度合い
• テスト担当者の経験の度合い
• 確認テストと回帰テストの実行度合い

リスク分析による調整

品質リスク分析の調整や新しいリスクの識別に関する活動には以下があります。

• 要件フェーズ中にリスク識別とアセスメントを実施しても設計仕様が完成したときに再評価する。
• テストでコンポーネントに含まれる欠陥の数が予想以上だった場合、リスクの全体のレベルを引き上げる（テスト量を増やす）。
• リスク識別時に要件に関する問題を検出した場合、要求仕様のレビューを実施する。

2.3.1.4 ライフサイクルにおけるリスクマネジメント

リスクマネジメントはライフサイクル全体で行うことが理想的です。
プロダクトリスクやプロジェクトリスクをテストでマネジメントするため、テストポリシーやテスト戦略についてドキュメントに記述します。
これにはリスクマネジメントをどのようにテストに統合するか示す必要がありますが、組織の成熟度によってもリスクマネジメントの手法は変わってきます。 

成熟した組織のマネジメント

成熟した組織では、様々な段階でリスクマネジメントを行います。

• 重要なリスクは初期のテストレベルでも対処します。
• リスクの識別だけでなく、原因と顕在化した場合の結果も識別します。
• 欠陥の根本原因分析を行います。
• リスクの軽減はライフサイクル全体で行います。
• リスク分析は関連する活動を考慮して行います。
• リスク分析はテストチームがプログラム全体のリスク分析に参加します。

 リスクベースドテスト技法のアプローチ

リスクベースドテストはリスクレベルによるテストの順序付けや優先度付けを行います。テストの実行には以下のようなアプローチがあります。

• 縦型探索（depth-first）：高リスクのテストを低リスクのテストより先にすべて実行する。
• 横型探索（breadth-first）：リスクに基づく重み付けを行い、サンプリングしたリスクアイテムを少なくとも1回は実行する。

テスト期間中にリスクベースドテストが終了しなかった場合には、管理部門がテストを延長するか残りのリスクを移転するか決定します。

洗練されたリスクベースドテスト技法

テストマネージャはステークホルダが理解できる方法でリスクに関するテスト結果を報告することで、ステークホルダがリスクの残存度合いを把握でき、リリースの決定を含むソフトウェア開発ライフサイクルのモニタリングとコントロールを可能にします。

2.3.2 リスクベースドテストの技法

リスクベースドテストを行う際、テストマネージャはステークホルダのニーズや期待、またプロセスに参加するために使用できる時間について理解する必要があります。
また、ステークホルダが品質リスク分析プロセスに適切に関与することで、要件が不明確なプロジェクトでも適切なチェックリストでステークホルダがリスク識別できるようになります。

リスクベースドテストの代表的な技法の一つに探索的テストがありますが、以下のようなメリット、デメリットがあります。

• メリット：テストをガイドするのに役立つ。
• デメリット：欠陥の影響ではなく欠陥の可能性に過剰に注目してしまう。テスト担当者のスキルに依存し、アプローチが主観的になる。

これらのアプローチがリスクベースドテストの利点を完全に実現することは難しいため、コストをできるだけ抑える軽量のリスクベースドテストを採用する実務者が多い。

非公式なリスクベースドテスト技法(軽量な技法） 

軽量のアプローチは以下の特徴を併せ持つことが多く、分析活動のリーダはステークホルダとともに最善の合意を形成させる必要があります。

• 非公式なアプローチの反応の早さや柔軟性
• 公式なアプローチの権限や合意形成

軽量なリスクベースアプローチ例

例１：要件ベースの戦略との併用が推奨される技法

• 実用的リスク分析とマネジメント(Pragmatic Risk Analysis and Management: PRAM)
• プロダクトリスクマネジメント(Product Risk Management: PRisMa)

例２：要求仕様が提供される戦略での技法

• 体系的ソフトウェアテスト(Systematic Software Testing: SST)

軽量な技法の属性

• 時間とともに進化
• ビジネス的および技術的観点のクロスファンクショナルなステークホルダによるチームの広範な関与
• 早期導入、品質リスク軽減や最小化できるように最適化
• アウトプットがテスト計画・条件とテストマネジメント活動・分析活動のベース
• テスト結果から残存リスクを見える化

軽量な技法の特徴

以下の特徴から柔軟性と広い範囲のドメインへの適用性、あらゆる経験とスキルを持つチームへのアクセシビリティを持ちます。

• 可能性と影響の2つの要因のみを使用
• シンプルで定性的な判断と尺度を使用

公式なリスクベースドテスト技法(重い技法）

公式で重い技法は以下のようなオプションを利用できます。

• ハザード分析：リスクの根底にあるハザードを識別する上流に分析プロセスを拡張する
• エクスポージャコスト：リスクアセスメントプロセスで以下の3つの要因を決める

1. リスクアイテムに関連する故障が発生する可能性
2. リスクアイテムに関連する一般的な故障が本番環境で発生した場合の損失コスト
3. 故障をテストするコスト

• 故障モードの影響解析(FMEA)やバリエーション：品質リスクや原因、起こりうる影響を識別して、重要度、優先度および検出率を導き出す
• 品質機能展開(QFD)：テストに関連する品質リスクマネジメント技法で、使用するユーザの要件に対する理解の誤り等による品質リスクに関連する
• フォールトツリー解析(FTA)：実際に観察された故障や潜在的な故障が分析対象となり、様々な根本原因を識別するまで分析する

リスクベースドテストの技法

リスクベースドテストで使用する具体的な技法や公式度は以下の考慮事項に依存し、入力/プロセス/出力は選択した技法により決定する傾向があるが、以下に示すものが一般的です。

リスクベースドテストを成功させるには、ステークホルダの適切なチームがリスク識別とリスクアセスメントに関与し、リスクレベルの評価に対して同じ尺度を使用して合意を形成することが重要となる。

考慮事項

• プロジェクト
• プロセス
• プロダクト

入力/プロセス/出力の一般例

• 入力：ステークホルダの知識、仕様、過去のデータ
• プロセス：リスク識別、リスクアセスメント、リスクコントロール
• 出力：品質リスク、入力ドキュメントで検出した欠陥、疑問点や問題、プロジェクトリスクのリスト

リスクベースドテストの終了作業

終了作業時にはリスクベースドテストの利点を実現できたかどうかを測定することで、品質リスク分析プロセスの効率性の改善に努める必要がある。テストマネージャは改善目標を達成するために、これらのメトリクスなどを慎重に考慮する必要がある。

成功したリスクベースドテストでは、以下の4つに肯定的な回答が得られます。

テストチームに対する確認事項

• 重要度の高い欠陥を多く検出したか
• テスト実行期間の早期に多くの重要な欠陥を検出したか
• テスト結果をリスク観点でステークホルダに報告したか
• スキップしたテストは実行したテストよりも関連リスクレベルは低いか

2.3.3 テストを選択するためのその他の技法

テスト技法はリスクベースドテスト以外にもあります。

要件ベースドテスト

テスト条件を作成して優先度付けをすることに優れています。

要件ベースドテストの技法

• 曖昧性レビュー：要件の欠陥チェックリストを使用することで要件の曖昧性を除去します。[Wiegers03]
• テスト条件分析：要求仕様からカバーするテスト条件を識別します（要件に優先度がない場合はリスクベースドテストと組み合わせて使用します）。[Craig02]
• 原因結果グラフ：非常に大きなテストの問題をマネジメント可能な数のテストケースに減らしてテストベースの機能を100%カバーします。また、テストケース設計時にテストベースのギャップを識別して早期に欠陥の識別できます。グラフ作成が複雑なため支援ツールを使用して作成します。

要件ベースドテストの障害

要求仕様について以下のような障害が存在する可能性があるが、これらの問題を解決しようとする組織はほとんどないため、テスト担当者は別のテスト戦略を選択する必要があります。

• 曖昧
• 検証不能
• 不完全
• 存在しない

別のテスト戦略

モデルベースアプローチ

要件を拡張するために、ユースケース、ユーザ、入力、出力を用いて実際の使用状況を正確に把握して、利用方法または運用プロファイルを作成します。これにより機能だけでなく使用性、相互運用性、信頼性、セキュリティ、性能のテストが可能になります。

テスト分析やテスト計画作業では、利用方法プロファイルを識別してテストケースからプロファイルの網羅を試みるが、利用方法プロファイルはソフトウェアの実際の利用状況の見積もりであるため、リスクベースドテストと同様に最終的な実際の結果のモデル化は難しい。適切なモデル化を行うためには、十分な情報とステークホルダの入力が必要となります。[Musa04]

方法論的アプローチ

何を、どのくらい、どの順序でテストするか、チェックリストなどの方法論アプローチによって決定します。
チェックリストを作成する場合、発生した変更の量に基づいて工数の割り当てとテストの順序を検討しますが、経験則による定義のため変更の量が多いと有効性が低下する傾向があります。

対処的アプローチ

テストの実行前に、分析作業、設計作業、実装作業をほとんど行いません。
テスト担当者はプロダクトに対して集中して、バグの偏在を検出するとテストを追加します。優先度付けと割り当ては動的に実施します。
対処的アプローチを単独で使用すると少数のバグしか発見できなかったアプリケーションのテストが不十分になる可能性があるため、他のアプローチを補完する目的で使用すると良いです。

2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て

テスト技法はプロジェクトやテストプロセスに組み込み優先度付けと工数の割り当てを行うために使用します。何のためにそのテスト技法を使用するのか考えることが重要です。

テスト計画作業とコントロール

リスク、要件、利用方法プロファイルが増大する程度を考慮して工数と優先度付けを行います。

シーケンシャルライフサイクル

テストチームは定期的な調整を行いつつ、要件フェーズでテストの選択と工数の割り当てを行い、テストの優先度付けを行う。

イテレーティブライフサイクル、アジャイルライフサイクル

イテレーション（繰り返し）ごとのアプローチが必要となります。

テストの分析、設計、実装

計画作業で決定された工数と優先度は、ガイドとして使用するだけでなく分析やモデリングを行うため、設計および実装のプロセスで詳細化します。

テストの実行

計画作業で決定した優先度に従ってテストを実行すべきですが、計画後に得られた情報により定期的に優先度を更新することも重要となります。

テスト結果と終了基準ステータスをレポートに残す場合、テストマネージャはリスク、要件、利用方法プロファイルおよびチェックリストに関して評価する必要があります。

さらに、テストを優先度付けするために使用したガイドについても評価してレポートに残します。

終了基準の評価

テストマネージャはテストの進捗レベルを測定します。

この測定ではテストケースと検出した欠陥が関連するテストベースまでさかのぼって追跡します。これにより未解決の欠陥のリスクレベルを把握でき、正しいリリース時期を決定するのに役立ちます。
テストレポートには以下の情報を記載する必要があります。結果レポートの例は[Black03]を参照。

• 実現された利点
• 実現されていない利点
• 対応済みのリスク
• 未対応のリスク

終了作業

ステークホルダのニーズと期待に関する確認を行うため終了基準の評価を行います。
このニーズと期待は機能だけではなく品質も含み、これらのニーズと期待を満たした場合のみテストチームが有効に機能したと言えます。