テストマネージャーにとって、**「テスト報告（Test Reporting）」**は、プロジェクトの品質状況を正しく伝えるための重要な業務です。
ISTQB Test Management v3.0の章2.1.3では、この「テスト報告」におけるメトリクス（Metrics）の活用方法が詳しく解説されています。
この記事では、
-
どんな種類のメトリクスを使えば良いのか
-
各テストフェーズでの活用方法
-
実務での報告のコツ
を、具体例を交えてわかりやすく解説します。
🎯 テストレポートの目的とは？
テストレポートの目的は、テストの進捗・品質・コストを「見える化」することです。
この情報をもとに、マネージャーやステークホルダーは「現状を正確に把握」し、「次の意思決定」を行います。
テストレポートには次のような特徴があります。
-
スナップショット報告：特定の時点での状況を報告
-
トレンド報告：時間の経過に伴う変化を報告（例：3スプリント分のバグ推移）
たとえばアジャイル開発では、スプリントごとに「前回よりバグが減っているか」「テスト完了率が上がっているか」などを可視化します。
このトレンド分析が、チームの改善サイクルに大きく役立ちます。
🧭 テストメトリクスの役割
**メトリクス（Metrics）**とは、「テスト活動を数値で表す指標」です。
ISTQBでは、次の5つの主要カテゴリに分類しています。
|
カテゴリ |
目的 |
|---|---|
|
① リスク関連メトリクス |
製品リスクのテスト状況を評価 |
|
② 不具合（Defect）メトリクス |
欠陥の傾向や品質問題を特定 |
|
③ テスト進捗メトリクス |
テスト作業の進行度を追跡 |
|
④ カバレッジ（Coverage）メトリクス |
どこまでテストできたかを測定 |
|
⑤ コスト・工数メトリクス |
実績と計画の差分を把握 |
これらの指標を組み合わせて、プロジェクト全体の健全性を判断します。
💡 各テストレベルに応じたメトリクスの使い分け
テストの種類によって、報告すべきメトリクスは異なります。
-
低レベルテスト（ユニット・コンポーネントテスト）
→ コードカバレッジ、分岐カバレッジ、パスカバレッジなど構造的指標を重視。
例：全関数の80%以上を実行済みか？
-
高レベルテスト（システム・受け入れテスト）
→ 要件カバレッジ、リスクカバレッジ、欠陥傾向などを重視。
例：顧客要求の95%がテストケースでカバーされているか？
つまり、**「どの段階で、何を測るか」**を正しく選ぶことが重要です。
📊 1. リスク関連メトリクス
目的： 製品リスクに対して、どの程度テストが完了しているかを示す。
主な指標
-
全テスト合格済みのリスク割合
-
一部または全テスト不合格のリスク割合
-
まだ未テストのリスク割合
実例
たとえば「ログイン機能に関するリスク」が10件あり、そのうち8件のテストが合格していれば、
リスク合格率 = 80% です。
これにより、どの領域がまだ不安定かを特定できます。
🐞 2. 不具合（Defect）メトリクス
目的： バグの発生傾向や品質問題を可視化する。
主な指標
-
累積発生バグ数 vs 修正済みバグ数
-
不具合の種類別（新機能、回帰、要件起因など）内訳
-
検出段階（単体、結合、受け入れ）別の欠陥率
-
優先度・重大度別の欠陥分布
実例
-
「受け入れテストでのバグ数が急増」
→ 要件レビュー段階での品質が不十分だった可能性。
-
「修正済みバグ率が90%超」
→ リリース準備が整いつつあるサイン。
🚀 3. テスト進捗メトリクス
目的： テストの完了度を把握し、スケジュールを調整する。
主な指標
-
テストケース数（計画・実施・完了・ブロック）
-
実行済みテスト数の割合
-
実施予定との乖離率
実例
|
状況 |
テスト進捗率 |
コメント |
|---|---|---|
|
計画100件中、80件実施済み |
80% |
進捗良好 |
|
ただしブロックテスト10件あり |
実質70% |
環境問題あり、早急な対策が必要 |
🧩 4. カバレッジ（Coverage）メトリクス
目的： どの程度テストが行き届いているかを測る。
種類と例
-
要件カバレッジ：全要件のうち、テストケースで検証済みの割合
-
リスクカバレッジ：特定のリスクに対して実施されたテスト割合
-
コードカバレッジ：実行されたソースコード部分の割合（例：ステートメント、分岐）
実例
「要件カバレッジが90%」
→ まだ10%の要件に対するテストケースが未作成。優先度を見直す必要あり。
💰 5. コスト・工数メトリクス
目的： 計画通りにリソースを使えているかを把握する。
主な指標
-
計画工数 vs 実績工数
-
テストコスト（計画費用と実績費用）
-
残リスク・未テスト領域のコスト影響
実例
「テスト環境トラブルで追加20時間発生」
→ 翌プロジェクトでは環境安定化にリソースを確保する、といった改善判断が可能になります。
🧠 メトリクスの組み合わせで洞察を深める
メトリクスは単体ではなく、複合的に使うことで本当の意味が見えてきます。
例：
-
「実行済みテスト数」と「未修正バグ数」を組み合わせることで、
テストの効率性や品質向上度を可視化。
-
「要件あたりの欠陥数」から、要求定義フェーズの品質を評価。
🏁 テスト終了（Exit Criteria）の判断
メトリクスの最終的な役割は、**「テスト終了の判断」**をサポートすることです。
新しい欠陥がほとんど発生せず、すべての重要なリスクがテスト完了となった段階で、
「終了基準（Exit Criteria）」を満たしたと判断します。
例：
-
重大度Aの欠陥が0件
-
リスクカバレッジが100%
-
テストケースの合格率が95%以上
これらの条件をもとに、テストマネージャーは正式にテスト完了を報告します。
✅ まとめ
テストレポートの本質は、単なる「数値の報告」ではなく、
**「現状を正しく伝え、次の意思決定を助ける」**ことにあります。
効果的なメトリクスの活用により、
-
プロジェクトの健全性を維持し、
-
品質改善のチャンスを見極め、
-
経営層や顧客に信頼される報告ができるようになります。
💬 まとめのポイント
-
メトリクスは「測ること」ではなく「活かすこと」が重要
-
テストレベルごとに適切な指標を選ぶ
-
トレンドとスナップショットを両方活用
-
終了判断はメトリクスとExit Criteriaで行う
コメント