Vietnamese
Englishリスクとテスト
リスクは、「将来、否定的な結果をもたらす可能性がある事象」として定義されます。リスクの程度は、その事象が発生する確率と、発生した場合に生じる影響（つまり損害）によって決まります。
言い換えれば、リスクとは、不利益をもたらす可能性のある「何か」のことです。この「何か」は、現実になる可能性（ここでは「可能性」と呼ばれる）と、現実になった場合に引き起こす損害の大きさ（ここでは「影響」と呼ばれる）の2つの観点から評価されます。リスクとして特定された場合、その重要性や対応の優先度を決めるために「リスクレベル」を設定します。
プロジェクトのステークホルダーやプロダクトのユーザーが被る可能性のある不利益を回避または軽減するための方法、すなわちリスクヘッジの手法について解説します。
リスクには大きく分けて、プロダクトリスクとプロジェクトリスクがあります。以下でそれぞれについて解説します。
プロダクトリスク
プロダクトリスクとは、「作業成果物（例：仕様書、コンポーネント、システム、テストケースなど）がユーザーやステークホルダーの正当なニーズを満たせないリスク」を指します。プロダクト自体がテスト対象であるため、テスト不足による損失やダメージをプロダクトリスクと捉えることができます。そのため、プロダクトリスクは開発プロセス全体に重大な影響を与える可能性がある要素として認識すべきです。
プロダクトリスクは、プロダクトが求められる品質基準に応じて異なります。以下に具体例を示します。
- 不具合のあるソフトウェアのリリース
リリース後に不具合が発生すると、修正対応に伴うコストが企業にとっての損失となります。 - ソフトウェアやハードウェアによる損害の可能性
不具合が原因で個人や企業に損害を与える場合があり、法的責任（製造物責任など）や損害賠償の対象となることがあります。また、訴訟リスクだけでなく、風評被害などの間接的な影響も懸念されます。 - 品質特性の低さ
機能は満たしていても、セキュリティや信頼性、パフォーマンスなどが不足している場合、製品の魅力や信頼性が低下します。 - データ完全性や品質の不備
データ移行や変換の問題により、プロダクトの機能性が損なわれることがあります。データの正確性や妥当性の検証が重要です。 - 予定された機能の動作不良
基本的な機能が正常に動作しない場合、顧客からの支払いが受けられない、または損害賠償を求められるリスクがあります。
リスクへの対応策
挙げられたリスクに対しては、事前予防策、事前準備策、事後対応策を検討します。すべてのリスクに対策を講じるわけではなく、リスクの発生確率や影響度（リスクエクスポージャー）を考慮して優先順位を決定します。これらの優先順位付けはプロジェクト計画段階から始まり、テスト計画でより具体化されます。
リスクの軽減方法として、最も分かりやすい手段はテストです。特にリスクの高い機能について、テストを通じて期待通りに動作することを確認することが重要です。テストは効果的な事前予防策の一つといえるでしょう。
テストを考慮しない場合、以下のようなリスクが顕在化する可能性があります。
・ソフトウェアが仕様通りに動作しない
・ユーザーやステークホルダーのニーズを満たさない
・システムアーキテクチャが非機能要件を十分に満たさない
・特定の計算結果が正確でない場合がある
・コードのループ制御に問題がある
・高負荷システムで応答時間が不適切
・ユーザーエクスペリエンス（UX）が期待に沿わない
リスクを的確に特定し、適切な対応を行うことは、プロダクトの品質と成功を確保するために欠かせません。
プロジェクトリスク
プロジェクトリスクとは、「発生した場合にプロジェクトの目標達成に悪影響を与えるリスク」と定義されます。プロジェクトリスクは、「ヒト、モノ、カネ」という観点から潜在的な問題を抱えており、テストの観点で管理すべき具体的な内容について以下に説明します。
ヒト
ヒトに関わる要因は、テストを実施する組織自体や、関連する他の組織の要因に分けられます。
- テストを行う組織やメンバー
テストプロセスを担うエンジニアやその所属組織を指し、スキル不足やトレーニング不足、適切な人員配置の欠如といったリスクが挙げられます。また、人員評価やフォローアップの不足もリスク要因となります。 - 他組織との連携
プロジェクト管理部門、開発チーム、サポート部門などの関係組織との連携が不十分だと、情報不足や計画ミスが発生する可能性があります。
モノ
モノは、テストに関わるハードウェア、ソフトウェア、ドキュメントなどの「テストウェア」を指します。必要なツールや機材が揃わない、または不備がある場合にリスクが生じます。
カネ
カネには、予算や実際のコスト、スケジュール管理に関連する費用が含まれます。直接的な人件費だけでなく、トレーニング費用や環境維持費用など間接コストも考慮する必要があります。
プロジェクトリスクの管理
プロジェクトリスクの管理は、計画段階で「ヒト、モノ、カネ」に関わる潜在的なリスクを洗い出し、それに対する対策を講じることから始まります。リスクが発生した場合には、計画時の対策を実行し、必要に応じて柔軟に見直すことが求められます。また、発生したリスクは単なるリスクとして扱うのではなく、「解決すべき問題」として具体的な対策を講じるべきです。
なお、プロジェクトリスクの管理は、プロジェクトマネージャーだけでなく、テストマネージャーも責任を共有する場合が一般的です。進捗全体はプロジェクトマネージャーが管理しますが、テストの進捗に関してはテストマネージャーが責任を持つことが多いです。
テストにおけるプロジェクトリスクの例
スケジュールリスク
・テストで大量の問題が検出され、進行が遅れる
・仕様変更や機能追加によって、テストケースの作成が遅れ、スケジュールが崩れる
テスト環境リスク
・必要な機材が調達できず、テスト環境が整備されない
・データ変換ツールの遅れにより、テスト環境用データが揃わない
・ステージング環境の構築に必要なツールに問題が発生する
テストマネジメントリスク
・必要なスキルや人数を持つ人材が確保できない
・テスト計画が不十分で、実行時にリソースが不足する
・無計画なリソース割り当てで予算が足りなくなる
プロジェクトリスクを適切に管理することで、テスト活動やプロジェクト全体の成功確率を高めることができます。
リスクベースドテストとプロダクト品質
「リスクベースのアプローチ」を導入することで、プロダクトリスクを軽減するための予防策を取ることができます。このアプローチでは、特定したリスクに対して以下のような対応を行います。
適用するテスト技法を決定する
リスクの優先度が高いと判断された機能に対しては、網羅率を高めるためのテスト技法を選定します。たとえば、ホワイトボックステスト技法ではデシジョンカバレッジ、ブラックボックステスト技法ではデシジョンテーブルテストを用いて、機能仕様を十分にカバーできるようにします。
テストレベルおよびテストタイプを設定する
過去に発見された欠陥の分布、欠陥修正がプロジェクトに与える影響、重要なテスト条件に対する高いカバレッジなどを考慮して、適切なテストレベルやテストタイプを選定します。
テスト実行の範囲を決める
テスト環境の準備範囲についてもリスクを基に検討できます。たとえば、Webアプリケーションをテストする際に、Internet Explorerのみを対象にするか、OperaやFirefoxを含めるか、さらにはどのバージョンまでテスト対象にするかを検討します。この際、ユーザー数やテストが不十分だった場合のクレームリスクなどを考慮し、テスト範囲を絞ります。
重大な欠陥を早期に検出するためのテスト優先順位の設定
市場で重大な欠陥が発生した場合の影響を最小限に抑えるため、重大な欠陥が含まれないように優先順位をつけてテストを実施します。重大な欠陥がテスト終了直前に発見されると、スケジュール遅延（プロジェクトリスク）の可能性が高まります。一方、スケジュールが遅れている場合でも、重大な欠陥を含む可能性がある機能をテストせずに完了することはできません。リスクベースで優先順位を設定することで、コストや納期に関する制約を緩和する助けとなります。
テスト以外の方法でリスク軽減を検討する
テストは予防策の一つであるため、それ以外の手段も検討します。たとえば、欠陥を発生させないプロセスの設計、開発者へのトレーニングやOJT、リスク発生時の影響を最小限に抑える機能追加などが含まれます。
リスクベースドテストは、ユーザー環境での故障リスクを最小化することを目的としています。そのためには、リスク分析・評価、重要度の決定、リスク軽減策（コンティンジェンシープラン）の策定といったリスクマネジメントの観点が必要です。以下はリスクベースドテストの進め方です。
リスクベースドテストの進め方
最初にリスク分析を行い、プロダクトリスクを識別・評価します。この分析は、プロジェクトのステークホルダーが持つ知識や洞察を活用して行います。この過程でリスクアイテムを特定し、それぞれの重要度を決定します。
プロダクトリスクに応じて、重要度に基づいたテストレベルや事前予防策を設計し、テスト計画に反映します。
リスク視点を重視することで、重要度の低いリスクに対しては動作確認のみで済ませる選択肢が取れる一方、重要度の高いリスクには十分なカバレッジを確保するため、トレーサビリティを明確にしてテストケースを作成する必要があります。たとえば、トレーサビリティマトリクスを用いて、すべてのプロダクトリスクに対応するテストケースが存在することを確認する方法があります。
計画段階で評価したリスクの重要度に基づいてテストを実行し、プロジェクト全体におけるプロダクトリスクの軽減状況をテストリーダーからプロジェクトマネージャーやステークホルダーに報告します。また、テスト中に新たなプロダクトリスクが明らかになった場合、その都度重要度を再評価し、テスト範囲や内容を見直します。
プロジェクトが進むにつれてリスクは変化するため、適時テストを見直すことが重要です。このように、リスクベースドテストでは、計画段階からリスクの重要度を評価し、プロジェクト進捗に合わせてリスク軽減状況を把握しながら柔軟に対応していきます。
欠陥の特徴
テストケースで設定した入力に対して、期待される結果と実際の結果が異なる現象（故障）の原因となるものが欠陥と呼ばれます。一般的に、期待結果と異なる現象が確認されることで欠陥の存在が疑われ、調査が必要だと判断されます。ただし、すべての現象が明確に欠陥だと特定できるわけではなく、そのような事象は「不正」（anomaly）と表現されています。
故障や不正の中には、調査の結果、テスト対象そのものには欠陥がなく、タイミングや外部環境などの影響により、期待結果と異なる観測結果が得られただけである場合もあります。このようなケースは欠陥ではないと判断され、「欠陥レポートに偽陽性が含まれる」と説明されています。
故障の発見やそれに起因する欠陥の検出は、テスト実行期間中だけでなく、開発中、レビュー中、その他のテスト活動、さらにはシステムの運用中にも行われます。また、欠陥はソースコードだけに存在するわけではなく、開発やテストに関連するドキュメント（例えば、仕様書やインストールガイド、ヘルプドキュメント）にも含まれることがあります。
欠陥マネジメントの必要性
欠陥に対応するためには、適切な活動を定義し、発見から修正完了までのプロセスを追跡・管理する必要があります。欠陥の管理プロセスは組織ごとに異なりますが、一般的には以下のステップで進められます。
- 故障（または不正）の発生を認識する
- 故障（または不正）を記録する
- 故障（または不正）の原因を調査する
- 影響範囲を分析し、欠陥を分類する
- 修正が完了するのを待つ
- 修正が終了したことを確認する
すべての欠陥を適切に管理するには、欠陥レポートを作成することが重要です。また、組織として欠陥管理プロセスを策定し、欠陥分類のためのルールを設定する必要があります。
欠陥レポート
欠陥を管理するには、発生したすべての欠陥を記録する必要があります。この記録はテスト担当者だけでなく、開発担当者や場合によっては顧客も行うことがあります。顧客が期待した結果と異なる現象を認識した際に、欠陥として記録される場合もあるためです。
欠陥レポートの目的は次の通りです。
- 情報の提供
開発担当者や他の関係者に対して、発生した期待に反する事象の情報を提供します。これにより、具体的な影響範囲を特定し、最小限の再現テストで問題を切り分け、欠陥の修正を可能にします。 - 品質とテストへの影響追跡
テストマネージャーに対して、作業成果物の品質やテストへの影響を把握する手段を提供します。欠陥の報告数が多い場合、テスト担当者はテスト実行よりも報告作業に時間を割く必要があり、追加の確認テストも求められることがあります。 - プロセス改善のヒント
開発プロセスやテストプロセスを改善するための示唆を提供します。
1つ目の「情報提供」は、比較的理解しやすい目的です。故障（または不正）を調査し、開発担当者が修正対象を正しく認識することで、迅速かつ正確な対応が可能になります。
欠陥レポートは、テストマネージャーにも重要な情報を提供します。欠陥の数や状態、修正の進捗状況を把握することで、テスト実行計画を効率的に作成できるからです。
※確認テスト