テスト管理のやり方を実務フローで解説　計画・設計・実行・不具合管理・報告までの進め方

テスト管理は、テストケースを実行して結果を記録するだけの作業ではありません。

テストの目的や範囲を決め、設計・実行・不具合管理・進捗報告・終了判定までを一連の流れとして管理し、リリース判断に必要な情報を整理する活動です。

現場ではテスト終盤になって未実行ケースが大量に残ったり、不具合の重要度や優先度が整理されないままリリース判定を迎えたりすることがあります。

こうした状況を防ぐには、テスト開始前の計画、実行中の進捗管理、不具合の可視化、終了時の報告までを仕組み化しておくことが重要です。

そこで今回はテスト管理の基本的な考え方から、テスト計画、テスト分析・設計、テストケース準備、テスト実行、不具合管理、終了判定・報告までの実務フローを解説します。

あわせて、テスト計画書で決めるべき項目、進捗管理で見るべき指標、不具合管理のポイント、失敗を防ぐチェックリストも紹介します。

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

テスト管理とは？実務で管理すべき範囲を整理する

テスト管理の目的

テスト管理とは、テスト計画からテスト報告までの流れが、当初の目的やスケジュールに沿って進んでいるかを確認し、進捗・品質・リスクを見える状態にする活動です。

JSTQBでも、テストマネジメントの役割はテストプロセス、テストチーム、テスト活動のリーダーシップに責任を持ち、主にテスト計画、テストモニタリングとコントロール、テスト完了に重点を置くとされています。

実務では、単にテストケースの消化数を見るだけでは不十分です。

テスト目的・範囲、テスト観点、ケース数、工数、環境、データ、体制、進捗、不具合、終了基準、品質評価、結果報告までをまとめて管理します。

特にリリース前は、PMや開発責任者が判断できるよう、未実行ケース、重大不具合、残リスクを根拠として整理することが重要です。

テスト対象そのものだけでなく、組織、リスク、テストウェア、不具合も管理対象に含めることで、属人的な進め方を防ぎやすくなります。

テスト管理で扱う主な項目

テスト管理で扱う項目は、テストの目的や範囲だけではありません。

どの要件をどの観点で確認するのか、どのテストケースを誰がいつ実行するのか、必要な環境やデータは準備できているのか、不具合が出た場合に誰がどの基準で優先度を判断するのかまでを整理します。

JSTQBでは、テスト計画の作業成果物にテスト計画書、スケジュール、リスク情報、開始基準、終了基準などが含まれ、テスト実行の成果物にはテスト結果記録や欠陥レポートが含まれると整理されています。

つまり、テスト管理は「進捗表を更新する作業」ではなく、テスト活動全体の状態を説明できるようにするための仕組みです。

テスト目的、範囲、観点、ケース、環境、体制、不具合、終了基準、報告の流れをあらかじめ決めておくことで、担当者が変わっても同じ判断ができる状態に近づきます。

テスト管理とテスト実行の違い

テスト実行は、テストケースに沿って操作し、期待結果と実結果を比較して、OK・NG・保留などの結果を記録する作業です。

一方、テスト管理は、テスト全体が目的通りに進んでいるかを監視し、遅延や品質リスクが見つかった場合に調整する活動です。

JSTQBでも、テストをする役割は主にテスト分析、設計、実装、実行に重点を置く一方、テストマネジメントの役割は計画、モニタリングとコントロール、完了に重点を置くとされています。

そのためテスト管理には実行担当者だけでなく、テストリーダー、QAリーダー、PMも関与します。

現場では「何件実行したか」だけでなく、「残っている未実行ケースにどれだけリスクがあるか」「NGや保留がリリース判断に影響するか」まで見て、関係者が判断できる形に整えることが求められます。

テスト管理の実務フロー 計画から終了作業までの進め方

1. テスト計画を立てる

最初に行うべきことは、テストの目的、対象範囲、対象外範囲を明確にすることです。

機能の正確性を重視するのか、性能、セキュリティ、互換性、業務シナリオを重視するのかによって、設計すべきテスト観点や工数は変わります。

ISO/IEC/IEEE 29119-2:2021では、テスト管理に関わるプロセスとして、テスト戦略と計画、テストモニタリングとコントロール、テスト完了が示されています。

テスト計画では、スコープ、リスク、体制、スケジュール、環境、開始基準・終了基準などを整理し、以降のモニタリングや完了判断の基準を作ります。

テスト計画では、スコープ、網羅性、優先度、入場基準、退場基準、終了基準、進捗確認方法、不具合対応のタイミング、カバレッジ管理方法を決めます。

ここが曖昧なままだと、テスト終盤に「どこまで確認すれば終わりなのか」が判断できなくなります。

初めてテストリーダーを担当する場合ほど、目的と範囲を計画書に落とし込み、PMや開発側と合意してから進めることが重要です。

2. テスト分析・設計を行う

テスト計画の次は、要件定義書、仕様書、画面設計書、API仕様書、ユーザーストーリーなどのテストベースを確認し、テスト条件やテスト観点を洗い出します。

ISTQBでは、テストの目的として、要件や設計などの作業成果物を評価すること、欠陥を見つけること、テスト対象に必要なカバレッジを確保することなどが挙げられています。

実務では、すべての機能を同じ深さで確認するのではなく、リスクの高い機能、利用頻度の高い機能、障害発生時の影響が大きい機能を優先します。

たとえば決済、ログイン、権限、外部連携、データ更新処理は、軽微な画面文言よりも優先度が高くなりやすい領域です。

境界値分析、同値分割、デシジョンテーブル、状態遷移などのテスト技法を使い、必要なパターンを過不足なく設計します。

あわせて、テスト環境、前提条件、外部サービスの利用可否もこの段階で確認しておくと、実行開始後の手戻りを減らせます。

3. テストケース・テストデータを準備する

テストケースは、担当者によって結果がぶれないように、手順、入力値、期待結果、前提条件を具体的に記載します。

「正常に動くこと」ではなく、「どの画面で、どの値を入力し、どの表示やデータ更新を確認するのか」まで書くことが大切です。

正常系、異常系、境界値、権限差分、業務シナリオを整理し、必要なテストデータ、アカウント、権限、外部連携条件も準備します。

自動化に向く繰り返し確認や回帰テストがある場合は、テストスクリプトの作成も検討します。

ただし、自動化は目的ではなく、確認品質と効率を上げるための手段です。

まずは手動で確認すべき観点と、繰り返し実行したい観点を分けると判断しやすくなります。

JSTQBでは、テスト設計や実装の成果物としてテストケース、テストチャーター、カバレッジアイテム、テストデータ、テスト環境などが整理されています。

4. テスト実行と証跡取得を行う

テスト実行では、テストケースに沿って操作し、期待結果と実結果を比較します。

結果はOK、NG、保留、対象外などのステータスで記録し、期待値と異なる結果が出た場合は、不具合報告や原因調査につなげます。

重要なのは、成功した結果だけでなく、失敗、保留、対象外の理由も記録に残すことです。

後からリリース判定を行う際、「なぜ未確認なのか」「どの条件でNGになったのか」が説明できなければ、品質判断の根拠が弱くなります。

証跡としては、画面キャプチャ、操作ログ、APIレスポンス、出力ファイル、DB更新結果などを残します。

特に再現条件が複雑な不具合では、実行環境、アカウント、データ条件、発生時刻を記録しておくと、開発側の調査が進めやすくなります。

テスト結果は、期待値に合ったかどうかに関係なく残すことで、進捗管理、不具合管理、報告書作成の土台になります。

5. 終了判定・報告・振り返りを行う

テストの終盤では、全テストケースの消化状況、未実行ケース、NGケース、保留ケース、未解決不具合、重大不具合、残課題を整理します。

そのうえで、計画時に定義した終了基準を満たしているかを確認します。

ISO/IEC/IEEE 29119-2でも、テスト管理プロセスにはテスト完了が含まれ、計画やモニタリングと並ぶ管理活動として扱われています。

テスト結果報告書では、単なる件数一覧ではなく、リリース判断に必要な情報をまとめます。

たとえば、テストケース消化率、重要機能の確認状況、未解決不具合の重要度と優先度、回帰テストの実施状況、残リスク、関係者への確認事項を整理します。

終了後は、テストケース、不具合傾向、環境トラブル、見積り差分、改善点をナレッジとして残します。

終了作業を省略せず、次回の計画や設計に活用できる形で資産化することが、再現性のあるテスト管理につながります。

テスト計画書で決めるべき項目｜属人化を防ぐ準備のやり方

テスト計画書が必要な理由

テスト計画書は、テスト範囲の抜け漏れを防ぎ、役割分担や判断基準を関係者で共有するための土台です。

計画書がないまま進めると、担当者ごとの判断に依存しやすくなり、テストケースの重複、対象外機能の混入、優先度の不一致、スケジュール遅延時の混乱が起こりやすくなります。

JSTQBでも、テストマネジメントはテストプロセス、チーム、活動のリーダーシップに責任を持つとされており、計画、モニタリング、完了を中心に活動します。

計画書には、テストの目的、範囲、前提条件、制約条件、観点、優先度、非機能要件、テスト方式、入力成果物、出力成果物、体制、承認者、スケジュール、環境、データ、不具合管理ルール、入場基準、退場基準、トレーサビリティを記載します。

これらを事前に決めることで、PM、開発者、テスターの認識をそろえやすくなります。

テスト目的・範囲の決め方

テスト目的を決める際は、何を確認できれば品質上の安心材料になるのかを明確にします。

機能の正確性を重視するのか、性能、セキュリティ、ユーザビリティ、業務継続性を重視するのかによって、必要なテスト観点は変わります。

対象機能と対象外機能を明確にし、重要度、利用頻度、障害影響度で優先順位を付けます。

範囲が曖昧なままだと、実行中に「この機能も見るべきではないか」という後戻りが発生しやすくなります。

また、要件とテストケースの対応関係を追えるようにしておくことも重要です。

JSTQBでは、テストベースとテストウェアの間のトレーサビリティを確立・維持することが、効果的なモニタリングとコントロールに重要とされています。

目的、範囲、優先度、トレーサビリティを計画時に固めることで、テスト実行中の判断が属人的になりにくくなります。

環境・ツール・スケジュールの決め方

テスト環境は、本番に近い条件をどこまで再現できるかを確認します。

OS、ブラウザ、端末、ミドルウェア、外部連携、権限、データ量などが本番と大きく異なる場合、テスト結果の信頼性に影響します。

テストデータについては、誰が、いつまでに、どの形式で、どの権限のデータを準備するのかを決めます。個人情報や機密情報を使う場合は、マスキングや利用ルールも必要です。

ツール面では、テスト管理ツール、課題管理ツール、チャット、ドキュメント管理場所を整理します。

ケース数が少ない場合はExcelでも運用できますが、複数人で同時に実行する場合や不具合件数が多い場合は、リアルタイムに進捗と不具合を確認できるツールの活用が有効です。

スケジュールは、設計、レビュー、環境準備、データ準備、実行、再テスト、報告の期間とマイルストーンを分けて定義します。

リスク・体制・成果物の決め方

テスト計画では、想定外の不具合、環境準備の遅れ、仕様変更、担当者不足、外部連携先の停止、テストデータ不足などのリスクを洗い出します。

リスクを事前に見える化しておくと、遅延や品質低下が起きたときに、スケジュール変更、要員追加、テスト範囲の見直し、優先度変更などを判断しやすくなります。

ISTQBの高度テストマネジメント領域でも、リスクベースドテストや品質リスクの識別、評価、軽減が扱われています。

体制面では、テスト設計者、実行者、レビュー担当、承認者、開発側窓口、PMとの報告経路を決めます。

成果物としては、テスト計画書、テスト仕様書、テストケース、不具合報告書、進捗レポート、テスト結果報告書を定義します。

リスク、体制、成果物を事前に決めることで、関係者が同じゴールを見ながらテストを進めやすくなります。

テスト実行中の進捗管理と不具合管理のやり方

進捗管理で見るべき指標

テスト実行中は、総テストケース数、実行済み件数、未実行件数、OK件数、NG件数、保留件数、対象外件数を日次で確認します。

さらに、ケース数ベースの消化率だけでなく、工数ベースの消化率、遅延日数、残工数も見ることが重要です。

1ケースあたりの実行時間がほぼ同じであれば件数ベースでも判断しやすいですが、複雑な業務シナリオや外部連携テストが含まれる場合、件数だけでは実態を見誤る可能性があります。

ケース数ベースの進捗は「消化ケース数÷総ケース数」、工数ベースの進捗は「消化済みケースの予定工数÷全ケースの予定工数」で見ます。

たとえば、簡単な画面確認を多く消化していても、重いシナリオテストが残っていれば、実質的な進捗は遅れている可能性があります。

ISO/IEC/IEEE 29119-2では、テストの測定結果を関係者へ伝達する活動もテストモニタリングとコントロールの一部として整理されています。

NG・保留ケースの扱い方

NGケースや保留ケースは、単純に未完了として数えるだけでは不十分です。

NGケースは、不具合修正にかかる日数、修正後の再テスト時間、関連機能への影響確認を見込む必要があります。

保留ケースは、仕様確認待ち、環境待ち、データ待ち、外部連携待ちなど、保留理由ごとに解消予定日と実行予定を決めます。

特に注意したいのは、消化率が高く見えても、NGや保留が多ければリリース判断には使いにくいという点です。

OKになるまでの残作業量を確認し、計画との差異を見て、スケジュール変更、要員追加、テストケースの優先度変更を検討します。

JSTQBでは、テストモニタリングとコントロールの成果物にテスト進捗レポートやコントロールのための指示文書が含まれると整理されています。

進捗管理は「予定通りか」を見るだけでなく、「予定通りに戻すには何を変えるべきか」を判断するために行います。

不具合管理で見るべき項目

不具合管理では、不具合件数だけでなく、重要度、優先度、発生機能、発生環境、発生原因、対応ステータス、クローズ状況、再現性、改修予定日、再テスト結果を管理します。

不具合票には、発生手順、期待結果、実結果、再現条件、証跡、環境情報を具体的に記録します。

これにより、開発側が調査しやすくなり、QA側も再テストの条件を揃えやすくなります。

重要度は利用者やシステムに与える影響の大きさ、優先度はどの不具合から先に対応するかの順番です。

たとえば、影響は大きいが特定条件でしか発生しない不具合と、影響は中程度でも多くの利用者が踏む不具合では、対応順が変わることがあります。

重要度・優先度の高い不具合が未クローズの場合、リリース判断に大きく影響します。不具合情報は、単なる修正依頼ではなく、リリース可否やテスト範囲見直しの判断材料として扱います。

不具合傾向を分析する

不具合は1件ずつ対応するだけでなく、傾向を見ることで品質リスクを把握できます。

機能別、テスト観点別、環境別、原因別、重要度別に件数を集計し、どこに不具合が集中しているかを確認します。

特定機能に不具合が集中している場合は、仕様理解の不足、設計の複雑さ、実装品質、テスト観点の不足が隠れている可能性があります。

また、計画値と実績値の差分も確認します。

想定より不具合が多い場合は、追加テスト、仕様再確認、回帰テスト範囲の拡大を検討します。

反対に不具合が極端に少ない場合も、テスト観点やケースの妥当性を確認する必要があります。

テスト管理の目的は、件数をきれいにまとめることではなく、品質上の懸念を早めに発見し、関係者が対策を取れる状態にすることです。

ISO/IEC/IEEE 29119-2でも、モニタリングは進捗やカバレッジの把握に使われるプロセスとして整理されています。

テスト管理を成功させる実務ポイントと失敗を防ぐチェックリスト

テスト管理者とPMの役割を分ける

テスト管理者は、進捗、不具合、品質状況、残リスクを収集し、現場の事実を見える形に整理します。

一方、PMはその情報をもとに、スケジュール変更、要員追加、リリース判断、追加対策を決めます。

テスト管理者がすべてを判断しようとすると負荷が集中し、PMが詳細を把握しないままだと判断が遅れます。

役割を分けたうえで、テスト管理者は「何が起きているか」「どの判断が必要か」「選択肢ごとのリスクは何か」を伝えることが重要です。

JSTQBでも、テストマネジメントの実施方法は状況によって異なり、アジャイルでは一部をチームが担当し、複数チームにまたがる場合はテストマネージャーが担うことがあるとされています。

実務では、進捗や不具合情報をもとに、現状維持、スケジュール変更、テストケース追加、範囲見直し、リリース延期などを検討できる報告に整えることが求められます。

リリース判断に必要な情報を整理する

リリース判断では、テストケース消化率だけでなく、未実行ケースの内容、未解決不具合の件数、重要度、優先度、重大不具合の有無、回帰テストの実施状況、テスト範囲の不足、残リスク、関係者への確認事項を整理します。

特に、未実行ケースが残っている場合は、件数ではなく「どの重要機能が未確認なのか」を示す必要があります。

不具合についても、総件数だけでは判断できません。重大度の高い不具合が残っているのか、回避策があるのか、修正予定日はいつか、再テストが完了しているのかを確認します。

ISO/IEC/IEEE 29119-2では、テスト管理プロセスがプロジェクトレベル、システムテスト、受け入れテスト、性能テスト、ユーザビリティテストなど、さまざまなレベルやタイプに適用できるとされています。

そのため、リリース判断では、対象プロジェクトで重視する品質特性に合わせて、判断材料を整えることが重要です。

よくある失敗と対策

テスト管理でよくある失敗は、目的と範囲が曖昧なまま始めることです。

この場合、計画段階で対象、対象外、優先度を明確にします。次に、テストケースの粒度がばらつく失敗があります。

これは、手順、期待結果、前提条件の書き方を統一することで防ぎやすくなります。進捗を件数だけで判断する失敗も多く、工数ベースの進捗やNG・保留の残対応を見る必要があります。

不具合の優先度が決まらない場合は、重要度と優先度の定義を事前に共有します。

終了作業を省略すると、次回以降に同じ問題を繰り返しやすくなるため、テストケース、不具合傾向、改善点を残すことが大切です。

添付プロンプトでも、未実行ケースの大量残りや不具合優先度の未整理を避け、テスト計画、進捗管理、不具合管理、報告の流れを理解したいニーズが示されています。

実務で使えるチェックリスト

実務では、テスト開始前に確認すべき項目をチェックリスト化しておくと、抜け漏れを防ぎやすくなります。

確認すべき内容は、以下のとおりです。

このチェックリストは、テストリーダーだけで使うのではなく、PM、開発リーダー、テスターと共有しておくと効果的です。

開始前に合意しておけば、実行中に判断が割れたときも、計画や基準に戻って話し合えます。

属人的な判断を減らし、テスト状況を数値と根拠で説明するための基盤になります。

テスト管理ツールを活用する場面

テスト管理ツールは、テストケース数が多い場合、複数人で実行する場合、不具合件数が多い場合、リアルタイムに進捗を見たい場合、テストケースと不具合を紐づけたい場合、レポート作成を効率化したい場合に有効です。

Excelでも小規模な管理は可能ですが、同時更新、履歴管理、権限管理、テストケースと不具合の関連付け、ダッシュボード化に限界が出ることがあります。

テスト実行状況や不具合情報は日々変化するため、最新状態をすぐ確認できる仕組みがあると、報告の属人化を防ぎやすくなります。

JSTQBでも、テストウェアにはテスト計画書、テストケース、テストデータ、テスト結果記録、欠陥レポート、テスト完了レポートなど多くの成果物が含まれると整理されています。

ツールは導入するだけでは効果が出ません。

ステータス定義、更新頻度、起票ルール、レビュー担当、レポート項目を決めて運用することで、進捗・品質・リスクを継続的に見える化できます。

まとめ

テスト管理を円滑に進めるには、計画・設計・実行・不具合管理・報告を分断せず、一連の実務フローとして整理することが重要です。

テスト開始前には、目的、範囲、対象外範囲、体制、スケジュール、環境、データ、入場基準・退場基準を明確にし、関係者間で合意しておく必要があります。

テスト実行中は、ケース数ベースの消化率だけでなく、工数ベースの進捗、NG・保留ケースの残対応、不具合の重要度・優先度、未解決課題を確認します。

特にリリース判断では「何件実行したか」だけではなく、「重要機能が確認済みか」「重大不具合が残っていないか」「残リスクを関係者が把握しているか」が問われます。

また、テスト終了時には、テスト結果報告書を作成し、未実行ケース、未解決不具合、回帰テストの状況、残課題、次回への改善点を整理します。

テストケースや不具合傾向をナレッジとして残すことで、次回以降のテスト計画や品質改善にも活用できます。

テスト管理は、属人的な判断を減らし、進捗・品質・リスクを根拠にもとづいて説明するための活動です。

計画段階で基準を決め、実行中は状況を可視化し、終了時には判断材料を整理することで、リリース直前の混乱や手戻りを防ぎやすくなります。

QA業務効率化ならPractiTest

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

この記事の監修

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

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