テスト管理におけるメトリクスとは

テスト管理では、テストケースの消化率や不具合件数を確認していても、「本当に品質は十分なのか」「リリースして問題ないのか」を判断しきれない場面があります。

消化率が高くても重要機能の確認が残っている場合や、不具合件数が少なくてもテスト観点が不足している場合があるためです。

そこで重要になるのが、テスト管理におけるメトリクスです。

メトリクスを活用すると、テストの進捗、品質状態、欠陥傾向、カバレッジ、修正状況などを数値で可視化できます。

これにより、感覚的な報告ではなく、根拠に基づいて品質状況やリスクを説明しやすくなります。

そこで今回はテスト管理におけるメトリクスの基本的な意味から、代表的な指標の種類、具体的な計算方法、管理・活用の流れ、運用時の注意点までを解説します。

品質会議やリリース判定で使える指標を整理したい場合は、ぜひ参考にしてください。

▼テスト管理ツール11製品の完全比較はこちら▼

メトリクスとは、品質や進捗を数値で可視化するための指標

テスト管理におけるメトリクスとは、ソフトウェアテストの状況を数値で把握するための指標です。

対象になるのは、テストの進捗、品質、欠陥状況、カバレッジ、プロセス効率などです。

たとえば、テストケース消化率、不具合件数、バグ密度、テスト密度、テストカバレッジ、欠陥修正リードタイムなどが代表例です。

重要なのは、メトリクスの目的が「数値を集めること」ではなく、「判断や改善に使うこと」にある点です。

テストケースを何件実行したか、不具合が何件出たかを記録するだけでは、品質管理としては不十分です。

その数値から、予定どおり進んでいるのか、特定機能にリスクが集中していないか、リリース前に追加確認が必要かを判断して、次のアクションにつなげる必要があります。

これらを組み合わせることで、感覚ではなくデータに基づいてテスト状況を説明しやすくなります。

テストメトリクスが必要とされる理由

テストメトリクスが必要とされる理由は、テスト状況を感覚ではなく客観的に把握するためです。

たとえば「テストは順調です」という報告だけでは、どの機能が完了していて、どこに遅れや品質リスクがあるのかが伝わりません。

一方で、テストケース消化率、未実行件数、Fail件数、Blocked件数、重大不具合の残数などを示せば、現状と課題を具体的に共有できます。

また、計画値と実績値を比較することで、進捗遅延や品質リスクを早期に発見できます。

テスト実行数が計画より少ない、特定機能で不具合が集中している、重大度の高い欠陥の修正が長期化しているといった兆候は、リリース直前ではなく途中段階で把握することが重要です。

プロジェクトマネージャー、プロダクトオーナー、顧客などのステークホルダーに対しても、メトリクスは品質状況を定量的に報告する材料になります。

メトリクスとKPIの違い

メトリクスとKPIは似た言葉ですが、役割が異なります。メトリクスは、状態を測るための数値指標です。

不具合件数、テストケース消化率、テスト密度、バグ密度、修正リードタイムなど、テスト活動や品質状態を把握するための数値は広くメトリクスに含まれます。

一方、KPIは目的達成度を判断するために特に重要な指標です。

たとえば、不具合件数そのものはメトリクスですが、「リリース判定時点で重大不具合ゼロ」「高リスク機能のテスト完了率100％」「欠陥除去効率が基準値以上」といった形で、プロジェクトの目標や判定基準に直結する場合はKPIとして扱えます。

注意したいのは、測れるものを何でもKPIにしないことです。

指標が増えすぎると、入力や集計に時間がかかる一方で、何を見て判断すべきかが曖昧になります。

テスト管理では、プロジェクトの目的に照らして、進捗、品質、リスク、リリース判断に関係する指標を選ぶことが重要です。

テスト管理で見るべき主要メトリクスの種類

進捗管理に関するメトリクス

進捗管理に関するメトリクスは、予定どおりテストが進んでいるか、どこで作業が止まっているかを把握するために使います。

代表的な指標には、テストケース作成数、テストケース実行数、テストケース消化率、Pass／Fail／Blocked／未実行の割合、計画工数に対する実績工数、テスト環境の利用可能時間などがあります。

テストケース消化率だけを見ると、進捗が良好に見える場合があります。

しかし、FailやBlockedが多い場合、実際には品質確認が完了していない可能性があります。

また、未実行のテストが高リスク機能に集中している場合、消化率が高くてもリリース判断には注意が必要です。

進捗管理では、単なる件数ではなく、遅延箇所やブロッカーを特定できる形で見ることが大切です。

品質評価に関するメトリクス

品質評価に関するメトリクスは、成果物やテスト対象の品質状態を把握するために使います。

代表例は、不具合件数、バグ密度、テスト密度、レビュー指摘密度、欠陥除去効率、重大度別・優先度別の不具合件数などです。

レビュー指摘件数はレビュー指摘密度、テストケース数はテスト密度、バグ件数はバグ密度の算出に使われます。

品質評価では、不具合件数が少ないことをそのまま「品質が高い」と判断しないことが重要です。

テストが十分に実施されていないために不具合が見つかっていない可能性もあります。

バグ密度、テスト密度、レビュー指摘密度、重大度別の不具合分布などを組み合わせることで、品質を立体的に判断しやすくなります。

カバレッジに関するメトリクス

カバレッジに関するメトリクスは、テストがどの範囲を確認できているかを把握するための指標です。

代表的なものには、要件カバレッジ、テスト条件カバレッジ、テストケースカバレッジ、コードカバレッジ、リスクカバレッジがあります。

要件カバレッジは、すべての要件のうち、どの要件がテストで確認済みかを見る指標です。

コードカバレッジは、ソースコードのうちテストで実行された範囲を示します。リスクカバレッジは、重要度や影響度が高いリスクに対して、どこまでテストが実施されているかを確認するために使います。

カバレッジは網羅性を確認するうえで有効ですが、カバレッジが高いことだけで品質が保証されるわけではありません。重要機能や高リスク領域が適切な観点で確認されているかまで見る必要があります。

不具合分析に関するメトリクス

不具合分析に関するメトリクスは、欠陥の発生傾向や修正状況を把握し、品質リスクの原因を探るために使います。

代表的な指標には、修正済み欠陥数／発見済み欠陥数、欠陥修正リードタイム、再オープン率、デグレード発生率、機能別・画面別・モジュール別の不具合分布、重大度別・原因別の不具合傾向などがあります。

たとえば、特定機能に不具合が集中している場合、設計が複雑なのか、仕様理解が不十分なのか、レビュー観点が不足していたのか、テスト設計が浅かったのかを確認する必要があります。

重大度の高い不具合が特定モジュールに偏っている場合は、追加テストやコードレビューの強化が必要になることもあります。

たとえばメトリクスに加えて、What、Where、When、Who、How、Whyの5W1Hで不具合を分析すると、原因を深掘りしやすくなるでしょう。

数値だけで終わらせず、原因と対策に結びつけることが不具合分析のポイントです。

プロセス改善に関するメトリクス

プロセス改善に関するメトリクスは、テスト活動そのものの効率や改善余地を把握するために使います。

代表的な指標には、テスト実行効率、欠陥修正時間、再テスト回数、レビューで検出できた欠陥の割合、自動化率、手戻り率などがあります。

たとえばテスト実行効率が低い場合、テストケースの粒度が細かすぎる、環境準備に時間がかかっている、手順が複雑で属人化している、といった原因が考えられます。

欠陥修正時間が長い場合は、仕様確認に時間がかかっている、担当者が不足している、再現手順が不十分であるなどの課題が隠れている可能性があります。

プロセス改善メトリクスは、現場の負担を増やすためではなく、ボトルネックを見つけて作業しやすい状態を作るために活用します。

テストメトリクスの具体例と計算方法

テストケース消化率

テストケース消化率は、テスト進捗を把握するための基本的なメトリクスです。

計算式は「実行済みテストケース数 ÷ 全テストケース数 × 100」です。たとえば、全1,000件のテストケースのうち700件を実行済みであれば、消化率は70％です。

ただし、消化率が高いからといって品質が十分とは限りません。

重要機能や高リスク領域のテストが未実行のまま残っている場合、全体の消化率が80％や90％であっても、リリース判断には慎重さが必要です。

また、実行済みの中にFailやBlockedが多い場合、確認が完了しているとは言えません。

そのため、テストケース消化率は、Pass率、Fail率、Blocked率、未実行率と組み合わせて見る必要があります。

さらに、機能別、担当者別、優先度別に分解すると、どの領域で進捗が止まっているのかを把握しやすくなります。

テスト密度

テスト密度は、開発規模に対して十分なテストケースが用意されているかを確認するための指標です。

計算式は「テストケース数 ÷ 規模」です。規模には、LOC、FP、画面数、機能数などが使われます。

また同じプロジェクト内でも、重要度や影響度によって機能ごとにテスト密度を変える場合があるとされています。

注意したいのは、テストケース数が多いほど品質が高いとは限らない点です。

重複したテストケースや観点の浅いテストケースが多くても、品質リスクを十分に下げられない場合があります。

重要機能、高頻度で使われる機能、障害時の影響が大きい機能では、リスクに応じてテスト密度を高める判断が必要です。

バグ密度

バグ密度は、対象プログラムや機能の品質を把握するための指標です。

計算式は「バグ件数 ÷ 規模」です。

規模には、LOC、FP、機能数、画面数などが使われます。単純な不具合件数だけでは、規模の大きな機能ほど不具合が多く見えやすいため、密度で見ることで比較しやすくなります。

また、規模の異なるソフトウェアやチーム間でも、傾向比較がしやすくなるとされています。

ただし、バグ密度が低い場合でも安心はできません。

テスト密度が低ければ、そもそも十分にテストされておらず、バグが見つかっていないだけの可能性があります。

そのため、バグ密度はテスト密度、レビュー指摘密度、重大度別不具合件数などと組み合わせて判断する必要があります。

欠陥修正リードタイム

欠陥修正リードタイムは、欠陥が報告されてから修正完了までにかかった時間を示すメトリクスです。

計算式は「欠陥報告日時から修正完了日時までの経過時間」です。修正対応の遅れや、開発・検証プロセス上のボトルネックを把握するために使います。

この指標は単純な平均値だけでなく、優先度や重大度別に見るとリリース判断に活用しやすくなります。

たとえば、軽微な不具合の修正に時間がかかっていてもリリース影響は限定的かもしれません。

一方で、重大不具合やセキュリティ関連の欠陥の修正リードタイムが長期化している場合は、リリース可否に大きく関わります。

長期化している不具合については、仕様が不明確なのか、設計に問題があるのか、担当者が不足しているのか、再現環境が整っていないのかを確認する必要があります。

欠陥修正リードタイムは、開発チームを責めるためではなく、修正を妨げている要因を明らかにするための指標です。

欠陥除去効率

欠陥除去効率は、テスト工程でどれだけ欠陥を検出できたかを見る指標です。

計算式は「テスト工程で検出した欠陥数 ÷ 全欠陥数 × 100」です。全欠陥数には、テスト中に見つかった欠陥に加えて、リリース後に発見された欠陥も含めて考えることがあります。

この指標が低い場合、テスト工程で十分に欠陥を検出できていなかった可能性があります。

リリース後不具合が多い場合は、テスト観点の不足、レビュー工程の弱さ、リスク分析の不足、実運用に近いシナリオの不足などを見直す必要があります。

欠陥除去効率は、単体テスト、結合テスト、システムテスト、受入テストなど工程別に見ると改善点を特定しやすくなります。

たとえば、システムテストで本来見つけるべき欠陥がリリース後に多く発生している場合、テスト設計や環境条件、業務シナリオの網羅性を見直すきっかけになります。

テストメトリクスを管理・活用する流れ

目的を明確にする

テストメトリクスを管理する最初のステップは、何のために測定するのかを明確にすることです。

目的の例としては、進捗遅延の早期発見、品質リスクの可視化、リリース判断、不具合傾向分析、プロセス改善などがあります。

目的が曖昧なまま指標を増やすと、集計作業だけが増え、実際の判断や改善に使われない状態になりがちです。

たとえば、テストケース消化率、不具合件数、修正リードタイム、自動化率などをすべて集計していても、会議で「結局どこにリスクがあるのか」が説明できなければ、メトリクスとして十分に機能していません。

まずは、品質会議やリリース判定で使う指標に絞ることが現実的です。

測定対象と収集ルールを定義する

目的を決めたら、次に測定対象と収集ルールを定義します。何を測るのか、誰が入力するのか、いつ更新するのか、どのタイミングで集計するのかを決めておく必要があります。

特に重要なのは、不具合1件のカウント基準です。同じ原因の不具合を1件とするのか、画面ごとに別件とするのかが曖昧だと、チームや担当者によって数値の意味が変わります。

また、重大度、優先度、原因分類、検出工程、発生機能、修正担当、再オープン有無などの入力ルールも揃える必要があります。

ルールが整っていないメトリクスは、あとから比較や分析に使いにくくなります。

最初から完璧を目指す必要はありませんが、最低限の定義をチームで共有することが重要です。

PDCAサイクルで運用する

テストメトリクスは、一度集計して終わりではなく、PDCAサイクルで運用することが重要です。

Planでは、目標値、基準値、収集項目、集計頻度を決めます。

Doでは、テストを実行しながらデータを収集します。

Checkでは、計画値と実績値を比較し、異常値や傾向を確認します。

Actionでは、追加テスト、レビュー強化、担当調整、納期調整などの対策を行います。

たとえば、特定機能のバグ密度が高ければ追加レビューや重点テストを実施し、Blockedが多ければ環境や仕様確認の優先度を上げます。

メトリクスは、過去を振り返るためだけでなく、現在のプロジェクトで次に何をするかを決めるために使うことが大切です。

ダッシュボードやテスト管理ツールで可視化する

テストメトリクスは、Excelで管理することもできますが、プロジェクト規模が大きくなるほど、Jira、TestRail、Azure DevOps、各種テスト管理ツールなどで一元管理するメリットが大きくなります。

テストケース、不具合、担当者、ステータス、期限、優先度、機能、リリースバージョンなどを紐づけることで、集計や分析がしやすくなります。

ダッシュボードでは、進捗率、未対応不具合数、重大不具合の残数、機能別不具合分布、Blocked件数、修正待ち件数、再テスト待ち件数などを見える化します。

会議のたびに手作業で集計するのではなく、できるだけ自動で最新状況を確認できる状態にしておくことが理想です。

メトリクス運用は、現場の入力負荷が高すぎると定着しません。

管理しやすい仕組みを作ることも、テスト管理の重要な役割です。

品質会議・リリース判定に活用する

テストメトリクスは、品質会議やリリース判定で特に効果を発揮します。

見るべき観点は、予定どおりテストが進んでいるか、品質リスクはどこにあるか、リリースしてよい状態か、残課題に対してどのような対応方針を持っているかです。

確認すべき材料には、重大不具合の残数、高リスク機能のテスト完了状況、修正待ち・再テスト待ちの件数、リグレッションテストの結果、未解決のBlocked件数、残存リスクと対応方針などがあります。

単に「不具合は何件です」と報告するのではなく、「この領域にリスクが残っているため、追加テストを実施する」「重大不具合は解消済みだが、再テスト待ちが残っている」といった判断につなげます。

メトリクスは報告資料の飾りではなく、意思決定とアクションの材料です。数値を使うことで、感覚的な品質報告から、根拠に基づく品質判断へ移行しやすくなります。

テストメトリクスを使う際の注意点

メトリクスは単独で判断しない

テストメトリクスは便利ですが、単独で品質を判断するのは危険です。

テストケース消化率が高くても、重要機能のテストが残っていれば安心できません。

不具合件数が少なくても、テスト観点が不足しているだけかもしれません。

バグ密度が低い場合も、本当に品質が高い場合と、十分にテストされていない場合の両方があります。

レビュー指摘密度も同じです。指摘が少ないからといって品質が高いとは限らず、レビュー工数やレビュー観点が不足していた可能性もあります。

品質を判断する際は、進捗、カバレッジ、不具合傾向、レビュー結果、修正状況など、複数のメトリクスを組み合わせて見ることが重要です。

数値の背景を確認する

異常値が出た場合は、数値だけで原因を決めつけないことが重要です。

不具合件数が多い場合でも、単純に実装品質が悪いとは限りません。

難易度の高い機能を担当している、仕様変更が多い、テスト観点が深くなった、過去よりも早い段階で欠陥を検出できている、といった背景がある場合もあります。

逆に不具合件数が少ない場合でも、テスト環境が使えず十分に実行できていない、確認観点が不足している、担当者が遠慮して不具合登録していない、といった問題が隠れている可能性があります。

また、データ分析後もコミュニケーションや現物確認が大切だとされています。

数値は出発点であり、背景確認まで行って初めて改善につながります。

報告相手に合わせて見せ方を変える

テストメトリクスは、報告相手によって見せ方を変える必要があります。

開発チーム向けであれば、機能別不具合、原因分類、修正リードタイム、再オープン率など、具体的な改善につながる情報が有効です。

PM向けであれば、進捗率、遅延リスク、残課題、リリース影響を中心に示すと判断しやすくなります。

経営層や顧客向けの場合は、細かい件数よりも、重大リスク、リリース可否、ビジネス影響、残存リスクへの対応方針が重要になります。

同じメトリクスでも、詳細な分析表をそのまま見せるのではなく、相手が意思決定に使える形に整理することが大切です。

メトリクスを増やしすぎない

メトリクスは多ければよいわけではありません。

指標が多すぎると、入力、集計、確認の負荷が増えます。

見る側も、どの数値が重要なのか判断しにくくなり、結果として会議で活用されないメトリクスが増えてしまいます。

最初から多くの指標を管理するのではなく、進捗、品質、不具合、カバレッジ、リリース判断に直結する指標に絞ることが現実的です。

たとえば、テストケース消化率、Pass／Fail／Blocked率、重大不具合の残数、バグ密度、テスト密度、要件カバレッジ、欠陥修正リードタイムなどから始めると運用しやすくなります。

個人評価や犯人探しに使わない

テストメトリクスは、個人評価や犯人探しに使うものではありません。

担当者別の不具合件数や生産性をそのまま評価に使うと、現場の協力が得られにくくなります。

不具合を登録しづらくなったり、難しい機能を担当する人が不利になったり、数値をよく見せるための行動が増えたりする恐れがあります。

メトリクスの目的は、「誰が悪いか」を探すことではなく、「どこに改善余地があるか」を見つけることです。

特定機能で不具合が多い場合は、担当者を責めるのではなく、仕様の複雑さ、レビュー体制、テスト観点、スケジュール、環境などを確認する必要があります。

メトリクスは、チーム全体で品質を改善するための共通言語として扱うことが重要です。

まとめ

テスト管理におけるメトリクスは、テストの進捗や品質を数値で可視化し、判断や改善につなげるための指標です。

代表的なものには、テストケース消化率、テスト密度、バグ密度、欠陥修正リードタイム、欠陥除去効率、要件カバレッジなどがあります。

ただし、メトリクスは単独で判断するものではありません。

たとえば、テストケース消化率が高くても高リスク領域のテストが残っていれば安心はできず、バグ密度が低くてもテスト不足によって不具合が見つかっていない可能性があります。

進捗、品質、不具合傾向、カバレッジ、修正状況などを組み合わせて見ることが重要です。

また、メトリクスは数値を集めること自体が目的ではありません。

品質会議での報告、リリース判定、追加テストの判断、レビュー強化、プロセス改善など、具体的なアクションにつなげてこそ意味があります。

まずは、進捗管理、品質評価、不具合分析、カバレッジ、リリース判断に直結する指標から選定し、収集ルールを明確にしたうえで運用を始めるとよいでしょう。

メトリクスをチーム共通の判断材料として活用できれば、属人的な品質判断を減らし、根拠に基づいたテスト管理を実現しやすくなります。

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ（マーケター、合同会社ぎあはーと代表）