JSTQB(ALTM) シラバス学習：2 テストメトリクスの定義および使用(2.6)
2.6 テストメトリクスの定義および使用
2019.02.18更新
テスト活動による結果を正しく判断するため、適切なテストメトリクスを定義する必要があります。
メトリクスの使用目的
分析
テスト結果から傾向と原因を探します。
レポート
テスト結果から気づいた点をプロジェクト参加者やステークホルダと共有して計画からの逸脱がないことを確認します。プロジェクトマネージャには欠陥についての詳細情報、ビジネスマネージャにはプロダクトリスクステータスが重要な情報となります。
コントロール
モニタリング結果から状況の変化に応じてテストやプロジェクト全体を見直し軌道修正します。
テストメトリクのカテゴリ
メトリクスのカテゴリは以下の1つ以上に分類されます。
例えば、メトリクスの一つである欠陥検出率を示す指標は終了基準、プロダクトの品質、テストプロセスの能力に関連付けできます。
プロジェクトメトリクス
プロジェクト終了基準（合格、不合格等）に対する進捗を測定します。
プロダクトメトリクス
プロダクトの属性（欠陥密度等）について測定します。
プロセスメトリクス
テストプロセスや開発プロセスの能力（検出された欠陥の割合）を測定します。
人的メトリクス
個人またはグループの能力を測定します。
メトリクスの利用
定義
プロジェクト、プロセス、プロダクトごとの目的に従い、有用な情報に限定して定義します。ステータスや傾向に誤解が生じないよう、バランスよく定義する必要があるが、多すぎもダメ。ステークホルダとの間で合意しておきます。
追跡
生データからメトリクス算出までは自動化すべきです。
メトリクスが変化する場合は合意した解釈以外の情報の影響を分析します。
レポート
速やかに理解できる情報にしておきます。
特定の時期のスナップショットや変化を抽出できるようにしておきます。
有効性
正確性、データから読み取れる情報を検証します。
メトリクスの種類
テスト計画のモニタリングメトリクス
- テストベースカバレッジ
- 欠陥検出
- テストケースの実行に関する計画時間と実時間
テスト分析活動のモニタリングメトリクス
- テスト条件の数
- テスト分析時に検出した欠陥の数
テスト設計活動のモニタリングメトリクス
- テスト条件を網羅している割合
- テスト設計時に検出した欠陥の数
テスト実装活動のモニタリングメトリクス
- 構築済みテスト環境の割合
- テストデータレコードの割合
- 自動化したテストケースの割合
テスト実行活動のモニタリングメトリクス
- 実行したテストケースの割合
- 実行したテストケースにより網羅したテスト条件の割合
- 欠陥の計画数と実際の数
- カバレッジの計画数と実際の数
テスト進捗および完了活動のモニタリングメトリクス
- プロダクトリスク、欠陥、テスト、テストカバレッジ、確信度合い
- 合格、不合格に分類した数
- 欠陥の総数を分類した数
- 変更の発生やテスト済みの数
- 計画と実際ののコスト、期間の比
- プロダクトリスクのステータス
- 進捗を妨げたイベントなどにより無駄になった活動の割合
- 確認テストと回帰テストのステータス
テスト終了活動のモニタリングメトリクス
- 実施、ブロック、スキップしたテストケースの割合
- 再利用可能なテストケースとしたテストケースの割合
- 自動化対応したテストケースの割合
- 回帰テストに統合したテストケースの割合
- 解決済みの欠陥レポートの割合
- 保管したテスト成果物の割合
2.7 テストのビジネスバリュー
- 過剰なテスト：遅延やコスト増により優れたビジネスバリューを提供しない
- 過小なテスト：欠陥の流出により優れたビジネスバリューを提供しない
上記の2つの間に存在する最適なテスト量が優れたビジネスバリューを提供すると認識し、ステークホルダが価値を理解できるように価値の定量化、記述など、明確な表現で示す必要があります。
価値の種類
どのような価値に当てはまるか理解することで適切な情報を提供することができます。
定量的価値
- リリース前に予防、修正する欠陥
- リリース前に判明する欠陥（回避策を文書化）
- テスト実行によるリスク軽減
- ステータスの情報提供
定性的価値
- 品質による評判向上
- 予定を立てやすいリリース
- 確信度合いの向上
- 法律上の免責
- システムの指名が果たされないリスク軽減
- 生命損失のリスク軽減
品質コスト
定量的価値や効率性を測定する方法のひとつで、プロジェクトや運用コストをプロダクト欠陥コストに関連する4つのカテゴリに分類します。
- 予防コスト：保守性、セキュリティ強化されたコードを書くためのトレーニング
- 評価コスト：テストケースの記述、テスト環境の構成、要件のレビュー
- 内部失敗コスト：テスト、レビューで検出した欠陥の修正
- 外部失敗コスト：提供したソフトウェアの欠陥のサポートコスト
また、テスト予算は評価コストと内部失敗コストの合計により示されます。
評価コストと内部失敗コストの合計は外部失敗コストを十分下回ることが、テストが優れた価値を提供していることを示す指標となります。
2.8 分散テスト、アウトソーステスト、およびインソーステスト
テスト活動はプロジェクトチーム自身が行うとは限りません。
テスト活動の種類
- 分散テスト：テスト活動を複数の地域で行う
- アウトソーステスト：プロジェクトチームと同じ地域にいない人が行う
- インソーステスト：プロジェクトチームと同じ地域にいるが同僚の従業員ではない人が行う
テスト活動に必要な定義
このようなテスト活動では、コミュニケーションの問題と期待との差異による問題を起こしやすいので、問題を避けるため以下のようなことを明確に定義することが必要となります。
誰がどこでテスト活動を行なったとしても、それぞれの役割に責任を持って活動できるように、自分たちが何のために何をすべきかを明確に理解できるようにマネジメントする必要があります。
これを成すことが、品質や納期の確保につながり、ステークホルダの信用を得ることにつながります。
2.9 業界標準適用のマネジメント
ソフトウェアテストには以下に示すような標準があります。
そこで、使用する標準を公式な標準、社内の標準、推奨事項のいずれに該当するのか整理する必要があります。また、複数の標準を使用する場合には、矛盾した定義などがないか確認が必要であったり、法的に準拠が必要なものがあったりするため、しっかりとした理解が必要となります。
- 国際標準
- 国内標準
- ドメイン固有の標準
標準の種類
以下に標準の分類と関連標準の例を示します。
国際標準
- ISO(International Standards Organization：国際標準化機構)：標準の推進
- IEEE(Institute of Electrical and Electronics Engineer：電気電子学会)：標準の提案
国内標準
- BS 7925-2(英国の国際標準)：テスト設計技法に関連する情報を記述
ドメイン固有の標準
- DO-178B(米国連邦航空局の標準)：民間航空機に使用するソフトウェアに適用され、致命度に基づく基準の設定
- Title 21 CFR Part 820(FDA：米国食品医薬品局)：構造的、機能的なテスト技法の提案
その他のフレームワーク
その他にもソフトウェア開発に関係するフレームワークがありますが、ISTQBの用語と異なるものもあるため、選択するフレームワークごとに用語の理解が必要となります。
