テスト管理項目の一覧　進捗・品質・不具合・工数で見るべき指標を解説

テスト管理では、テストケースを何件実行したかを確認するだけでは不十分です。

予定通りに進んでいるように見えても、重要機能のテストが残っていたり、重大不具合が未解決だったり、想定以上に工数を使っていたりする場合があります。

進捗率だけを見て「順調」と判断すると、リリース直前に品質リスクや工数超過が表面化することもあります。

そのためテスト管理では、進捗、品質、不具合、工数の4つの観点から状況を見える化することが重要です。

そこで今回はテスト管理で見るべき項目を一覧で整理し、進捗管理・品質管理・不具合管理・工数管理それぞれで確認すべき指標を解説します。

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

テスト管理で見るべき項目は「進捗・品質・不具合・工数」の4つ

テスト管理は「実行件数を数えるだけ」では不十分

テスト管理では、テストケースを何件実行したかだけでなく、テストの進み具合、不具合の発生状況、作業負荷、品質リスクをあわせて見える化することが重要です。

ISTQBのFoundation Levelでも、テスト活動の管理領域にはテスト計画、リスク管理、テスト監視・コントロール、完了、不具合管理が含まれ、進捗と品質を効果的に報告することが成果の一つとして示されています。

つまり、テスト管理者の役割は「予定通り進んでいます」と報告するだけではありません。

不具合の規模や傾向、未消化テスト、重大不具合の残り方、工数の超過兆候を集め、PMがテスト追加、リリース時期の見直し、テスト範囲の変更を判断できる材料を整えることです。

管理項目を4分類にすると状況を説明しやすい

テスト管理項目は、「進捗・品質・不具合・工数」の4つに分けると、定例会議や顧客報告で状況を説明しやすくなります。

進捗では、テストが計画通りに消化されているかを、予定件数、実施件数、残件数、進捗率で確認します。

品質では、十分な観点と密度でテストできているかを、テスト網羅率、合格率、不合格率、不具合密度などで見ます。

不具合では、件数だけでなく、重大度、優先度、未解決件数、再オープン件数、滞留日数を確認し、問題の重さや偏りを把握します。

工数では、予定工数、実績工数、残工数、工数差異を見て、計画した人員と時間で収まっているかを判断します。

テスト指標は進捗、品質、生産性を追跡し、改善や意思決定に使われるものと整理されています。

進捗管理の項目

まず見るべき進捗管理項目一覧

進捗率だけで判断しない

テスト進捗を見るときは、進捗率だけで「順調」と判断しないことが重要です。

ソフトウェアテストのメトリクスは、テスト活動の進捗・品質・効率を評価し、データに基づく意思決定を支える指標とされています。

単に実施済み件数が増えていても、重要機能やリスクの高い機能が未実施のままなら、リリース判断に使える進捗とはいえません。

たとえば、画面表示や入力チェックなど比較的簡単なケースだけが先に終わり、決済、権限、外部連携、バッチ処理など難易度の高いテストが終盤に残ると、後から重大不具合や仕様確認が集中しやすくなります。

そのため進捗は、全体の進捗率に加えて、機能別、優先度別、担当者別に分けて確認します。

リスクベースドテストでも、影響度や発生可能性の高い領域にテストを優先配分する考え方が重視されています。

遅延のサイン

進捗遅延は、ある日突然発生するのではなく、日々の数字に小さなサインとして表れます。

特に確認したいのは、予定進捗率と実績進捗率の差です。

差が1日ごとに広がっている場合、単なる一時的な遅れではなく、テストケースの難易度、環境不備、仕様確認待ち、担当者の負荷集中など、構造的な問題が起きている可能性があります。

テスト進捗の追跡では、計画済みテストケース数、完了済みテストケース数、未計画・追加ケース数などを測定し、遅れを早く見つけることが有効とされています。

また、保留件数が減らない状態も注意が必要です。

保留の中には、環境待ち、仕様確認待ち、不具合修正待ちなど、チーム外の要因で止まっているものが含まれます。

特定機能だけ未実施件数が多い、1人の担当者に未実施ケースが集中している、といった偏りも遅延のサインです。

管理表では、未実施件数、保留件数、予定との差分、機能別残件数、担当者別残件数を並べて見ることで、どこに手を打つべきかを説明しやすくなります。

品質管理の項目

まず見るべき品質管理項目一覧

テスト密度・不具合密度で品質を説明する

品質を見る項目では、テストが何件終わったかだけでなく、開発規模に対して十分な量と深さで確認できたかを見ます。

代表的な指標が、テスト密度と不具合密度です。

テスト密度は、開発規模に対してどれだけテストケースを用意・実施したかを示す指標で、一般的には「テストケース数 ÷ 開発規模」で算出します。

不具合密度は、検出した不具合件数を開発規模で割って評価する指標で、「不具合件数 ÷ 開発規模」で見ます。

品質指標を見るときの注意点

品質指標を見るときは、不具合が少ないから品質が良い、とすぐに判断しないことが大切です。

不具合件数が少ない場合でも、テストケースの質が低い、重要な業務フローを確認できていない、テスト環境に制約があり実運用に近い条件で試せていない、といった理由で不具合を見つけられていないだけの可能性があります。

特に総合テストでは、進捗率、合格率、不具合件数だけでなく、未テスト範囲、仕様変更の残り、外部連携や権限など高リスク領域の確認状況も合わせて見る必要があります。

テスト密度の目標値は、社内基準があればそれを使い、ない場合はIPAなどの公開データを参考にしながら、プロジェクト特性に合わせて決める考え方が紹介されています。 

そのうえで、過去プロジェクトや類似機能と比べて、テスト密度や不具合密度が極端に低い・高い箇所を確認すると、品質リスクを説明しやすくなります。

不具合管理の項目

まず見るべき不具合管理項目一覧

不具合は「多い・少ない」だけで判断しない

不具合管理では、件数の増減だけで品質を判断しないことが重要です。

未解決件数が少なくても、業務停止、データ不整合、セキュリティ、決済、権限などに関わる重要度の高い不具合が残っていれば、リリースリスクは高いままです。

一方で、文言ずれや表示崩れなど軽微な不具合が多くても、業務影響が小さく、回避策も明確であれば、対応優先度は下がる場合があります。

ISTQBでは、テストマネジメントや欠陥処理がソフトウェアテストの基礎知識に含まれ、欠陥情報は品質判断や対応方針の整理に使われる領域として扱われています。 

そのため管理表には、不具合ID、発生日、発生機能、重要度、影響度、優先度、分類、ステータス、担当者を入れ、単なる件数集計ではなく「どの不具合から直すべきか」が見える状態にします。

不具合滞留を見ると開発・QAの詰まりが分かる

不具合の滞留状況を見ると、開発側とQA側のどこで作業が詰まっているかを把握しやすくなります。

たとえば「修正待ち」が多い場合は、開発側の対応キャパシティ不足、原因調査の難航、仕様確認待ちが疑われます。

「再テスト待ち」が多い場合は、QA側の確認作業が追いついていない、環境準備やデータ作成に時間がかかっている可能性があります。

また差し戻しや再オープンが多い場合は、修正品質、影響範囲の確認、仕様理解に問題があると考えられます。

リリース後不具合の要因として、仕様書の不備、改修による影響範囲の考慮漏れ、テスト粒度不足などが挙げられており、同じ機能で不具合が再発する場合は、表面的な修正だけでなく設計・実装・テスト観点の根本原因を確認する必要があります。 

管理項目としては、ステータス別件数、滞留日数、再オープン件数、差し戻し回数、機能別発生件数を押さえると、対策の優先順位を説明しやすくなります。

リリース判定で確認すべき不具合項目

リリース判定では、「不具合が何件残っているか」よりも、「残っている不具合を受け入れられるか」を確認します。

最低限見るべき項目は、重大・高優先度の未解決不具合、顧客影響・業務影響、回避策の有無、修正予定日、リリース後対応に回す場合の合意状況です。

特に、業務停止やデータ破損につながる不具合は、件数が1件でもリリース延期や追加テストの判断材料になります。

一方、影響範囲が限定的で、運用回避策や修正予定日が明確であり、顧客・業務部門・開発側の合意が取れているものは、残リスクとして管理しながらリリース後対応に回す選択肢もあります。

不具合は、期待した通りに機能していない状態や、正常な状態から逸脱している事象を指すため、原因が未確定でもリスクとして扱う必要があります。

未解決不具合一覧を重要度順に並べ、影響、回避策、対応期限、合意者をセットで確認できる形にしておくと、感覚ではなく数字と根拠に基づいて説明できます。

工数管理の項目

まず見るべき工数管理項目一覧

工数は進捗とセットで見る

工数は、テストの進捗率と必ずセットで確認します。

ケース数だけを見ると順調に見えても、実際には想定以上の時間を使っている場合があります。

たとえば、工数消化率が高いのに進捗率が低い場合は、テストケースの見積もりや設計に無理がある、テスト環境が不安定、仕様確認に時間がかかっている、手戻りが多いといった問題が考えられます。

逆に、進捗率が高くても工数がすでに超過している場合は、終盤に残る再テストや不具合対応でさらに超過する可能性があります。

テスト管理では作業量と必要工数を結びつけて見ることが大切です。

工数超過のサイン

工数超過のサインは、実績工数が予定工数を超えた時点で初めて見るのでは遅く、日々の作業内訳から早めに拾う必要があります。

特に、不具合対応や再テストの工数が増えている場合は注意が必要です。

保留の場合も、原因解消までの日数と実行時間を合わせて見る必要があります。

また保留解除後にまとめて作業が発生している、仕様変更によるテストケース追加が続いている、特定メンバーの残業や作業集中が増えている場合も、工数超過の前兆です。

管理表には、予定工数、実績工数、残工数、工数差異、再テスト工数、不具合対応工数、追加テスト工数、担当者別工数を入れておくと、追加要員が必要か、スコープ調整が必要かを説明しやすくなります。

メトリクスは進捗や資源利用、成果物の状況を定量的に示し、品質確保やコスト管理に使われるものとされています。

そのまま使えるテスト管理表の項目例

テスト管理表に入れる基本項目

テスト管理表には、テストの進み具合、不具合の状況、作業工数、品質リスクを同じ粒度で確認できる項目を入れます。

テスト管理では、テストケースの消化状況や作業工数、不具合の規模・傾向・クローズ状況を可視化し、PMがテスト追加、リリース時期変更、テスト範囲変更を判断できるようにすることが重要とされています。

基本項目としては、テストケースID、機能名、テスト観点、優先度、担当者、予定日、実施日、ステータス、実施結果、保留理由、不具合ID、重要度、修正担当、再テスト結果、予定工数、実績工数を入れておくと運用しやすくなります。

さらに、進捗率、未実施件数、保留件数、重大不具合件数、未解決不具合件数、工数差異を集計できる形にしておくと、定例会議や顧客報告で「どこが遅れているか」「品質上の懸念は何か」「追加対応が必要か」を説明しやすくなります。

毎日見る項目と週次で見る項目を分ける

テスト管理表は、すべての項目を毎日同じ重さで見るのではなく、日次確認と週次確認に分けると運用しやすくなります。

日次では、テスト実行数、残件数、進捗率、予定との差分、保留件数、当日発生不具合、重大・高優先度の未解決不具合、担当者別の作業集中を確認します。

テスト監視では、計画に対する進捗、終了基準の達成状況、欠陥ステータスなどを見て、テスト作業が完了に近づいているかを判断する考え方があります。

一方、週次では、機能別の進捗推移、不具合の発生傾向、再オープン件数、テスト密度、不具合密度、予定工数と実績工数の差、追加テストの必要性を確認します。

毎日は現場の詰まりを見つけ、週次ではリリース判断に向けた品質と工数の見通しを確認する、という役割分担にすると、管理表が単なる記録ではなく意思決定に使える資料になります。

まとめ

テスト管理で見るべき項目は、大きく「進捗・品質・不具合・工数」の4つに分けて整理すると、状況を把握しやすくなります。

進捗管理では、実施済み件数や進捗率だけでなく、未実施件数、保留件数、機能別進捗、担当者別進捗を確認し、遅延や作業負荷の偏りを早めに見つけることが重要です。

品質管理では、合格率や不具合件数だけで判断せず、テスト密度、不具合密度、重要機能の消化率、未確認範囲、残存リスクをあわせて見ます。

不具合が少ない場合でも、十分にテストできていないだけの可能性があるため注意が必要です。

不具合管理では、件数の多い・少ないだけでなく、重要度、優先度、未解決件数、滞留日数、再オープン件数を確認します。

特にリリース判定では、残っている不具合を受け入れられるか、回避策や合意があるかを確認することが大切です。

工数管理では、予定工数、実績工数、残工数、工数差異を進捗率とセットで見ます。

工数だけ消化して進捗が伸びていない場合や、不具合対応・再テスト工数が増えている場合は、計画見直しや追加要員の検討が必要です。

テスト管理表には、テストID、機能名、担当者、ステータス、実施結果、不具合ID、重要度、予定工数、実績工数などを入れ、日次では現場の詰まりを、週次では品質リスクや工数の見通しを確認できる形にしておきましょう。

テスト管理は、単なる記録作業ではなく、リリース可否や追加テスト、スケジュール調整を判断するための材料を整える活動です。

4つの観点で項目を管理することで、現場の状況を客観的に説明しやすくなります。

テスト管理項目を継続的に見るなら、PractiTestの活用がおすすめ

進捗・品質・不具合・工数を正しく管理するには、Excelやスプレッドシートで項目を並べるだけでなく、日々の更新、集計、共有、レポート化を無理なく続けられる仕組みが必要です。

手作業で管理していると、テストケースの実施状況、不具合のステータス、担当者別の残作業、重大不具合の残り方などを確認するたびに集計が発生し、報告資料の作成にも時間がかかります。

そこでオススメなのが、テスト管理ツールのPractiTestです。

PractiTestは、テストケース、実行結果、要件、不具合などのテスト資産を一元管理できる総合テスト管理ツールです。

ダッシュボードで進捗や品質状況をリアルタイムに可視化できるため、未実施件数、保留、不具合の残り方、品質リスクをすばやく把握できます。

また、テストケースの再利用やプロジェクトに合わせた柔軟なカスタマイズに対応しており、継続的なテスト管理にも向いています。

さらに、Jira Software、Azure DevOps、Slackなど外部ツールとの連携により、開発・QA間の二重管理を減らし、要件からテスト、不具合までのトレーサビリティを高められます。

大規模プロジェクトや複数プロダクトの運用にも対応し、ISO/IEC 27001:2022認証、SSO、MFA、監査ログなどセキュリティ機能も充実しています。

日本語UIと国内代理店による日本語サポートがあるため、導入後の運用も安心です。

テスト管理を単なる記録作業で終わらせず、品質と工数を継続的に改善する仕組みに変えたいなら、PractiTestの活用を検討してみてはいかがでしょうか。

QA業務効率化ならPractiTest

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