テスト実行とは？開始前の確認5項目と判定・記録・不具合報告の進め方

「テスト実行に入ったものの環境やデータが揃わず手が止まる」「不具合を報告しても、開発者が現象を再現できず、報告者に手順の追記が求められる」「手戻りが重なりリリース直前に納期が逼迫する」といった課題に悩む現場は少なくありません。

テスト実行の遅延や品質のばらつきの原因の多くは、実行担当者のスキル不足ではなく、実行前に行うべき「準備の漏れ」や「ルールの曖昧さ」にあります。手戻りのないテスト実行を実現するには、直前の「テスト実装」との役割分担を整理し、実行順序の設計、判定区分の定義、エビデンス取得ルールを着手前に確立しておくことが不可欠です。

本記事では、テスト実行とテスト実装の違い、前工程で整えておくこと、開始前の確認5項目、実行・記録・不具合報告と再テストの進め方を解説します。

テスト実行とは？テスト実装との違い

テスト実行とは、テストケースに記載された手順どおりにソフトウェアを操作し、期待結果と実際の挙動を突き合わせて合否を判定し、エビデンスを記録する工程です。役割は「動かす・比べる・記録する」に集約されます。

一方、テストデータの作成やテストスイートの編成は、直前の「テスト実装」工程が担います（出典：JSTQB「テスト技術者資格制度 Foundation Level シラバス（Version 2023V4.0.J02）」2023年）。両者を分けて捉え、実装工程の完了条件を定めることで、「実行に入ったのにデータがない」「環境が動かない」といった事態を事前に防ぐことができます。

なお、現場では「テスト実施」と「テスト実行」が同義で使われますが、認識のずれを防ぐためプロジェクト内で呼称を統一しておくことが推奨されます。本記事では「テスト実行」に統一します。

【計画〜実装段階】テスト実行までに整えておくこと

実行担当者が着手する前に、テスト責任者と各準備の担当者が必要なルール・環境・データを整えます。計画段階で検討することと、実装完了までに用意するものを分けて確認しましょう。

2-1. 【計画段階】判定・記録のルールと実行条件を決める

計画段階では、テスト責任者を中心に、使用するツール（テスト管理、BTS、ログ取得など）や判定ステータス、エビデンスの取得対象・タイミング・保存先のフォルダ構成・命名規則を検討し、ルールを定めます。ルールが決まっていないと証跡が個人のローカルに散逸し、後から第三者が確認できなくなってしまいます。

制約事項は「時間」「接続」「機能」の3つの切り口で洗い出します。

• 時間の制約：環境利用可能期間、端末共用時間帯、夜間バッチ時刻
• 接続の制約：外部連携システムの接続可能日時、データ更新サイクル
• 機能の制約：検証環境のライセンス制限、本番専用サービス

工数は計画段階で見積もり、テストケースの具体化に合わせて見直します。「表示確認」「単一画面操作」「複数画面操作」「応答待ちあり」などにケースを分類し、分類ごとの1ケース当たりの想定所要時間に件数を掛けて積算します。不具合起票や再テストの工数も予備として含めておくことが重要です。

2-2. 【実装完了まで】環境・データ・実行順序を整える

テスト設計で具体化した環境・データの要件に沿って、実装完了までに次の準備を進めます。

1. テスト環境・データ・ツールを用意する

環境準備には、専用端末や通信機器、実機端末の調達・貸出手続きが含まれます。実行当日に「OSバージョンが違う」「ライセンスが不足している」といった不備が出ないよう、手配・設定・動作確認を済ませます。

テストデータは、テストケースの前提条件（正常値・境界値・不正値・権限別アカウントなど）と紐づけて作成します。

使用するツールの導入、アカウントの発行・権限設定、エビデンス保存先の用意も済ませます。

2. 実行日程と順序を調整し、担当者に共有する

洗い出した制約には代替手段（連携日へのケース集約やモック利用など）を用意します。また、日付変更や月次バッチなど日をまたいで検証するケースは、実行できる日時に合わせてスケジュールを調整します。

実行順序は、「依存関係」「重要度と手戻りの大きさ」「作業効率」の3軸で調整します。

• 依存関係による順序設計：会員登録など前提データを作る操作は、そのデータを使うケースより先に配置します。マスタ初期化やデータ削除を行うケースは、後続への影響を確認して配置します。
• 重要度による優先付け：決済や認証などの基幹機能は、不合格時に修正待ちが発生し再テスト範囲も広がるため、序盤に配置して手戻りリスクを抑えます。
• 作業効率の考慮：同一設定で流せるケースをまとめると設定変更の往復も減らせます。

参照資料と保管場所、判定・記録のルール、担当ケースと予定工数を実行担当者へ共有し、開始前に確認できるようにしておきます。

バルテスのテスト管理ツール「QualityTracker」では、ケースの見積もり時間と実行者の生産性から自動アサインが可能です。EVMによる進捗計算やダッシュボードにより、計画と実績の乖離を素早く検知できます。

【実行開始前】実行担当者が確認する5つのこと

テスト実装が完了したら、実行担当者は自分の担当ケースを実行できる状態か確認します。仕様の理解、環境やデータの利用可否、権限の不足などを開始前に確かめることで、実行中の手待ちを防ぎます。

実行開始前に確認する項目は次の5点です。

• 仕様書とテストケースを読み、期待結果を理解する
• テスト環境とデータが担当ケースの条件に合うか確認する
• ツールの操作権限と判定・記録のルールを確認する
• 実行を妨げる制約やブロッカーを確認する
• 担当ケースの実行順序と予定工数を確認する

3-1. 仕様書とテストケースを読み、期待結果を理解する

実行担当者は開始前に関連資料を読み込み、テストの進め方と期待結果の根拠を確認します。事前に読み込む対象は、進め方を把握するための「テスト側ドキュメント（計画書・テスト仕様書）」と、正しい挙動を理解するための「開発仕様側ドキュメント（要件定義書・画面仕様書など）」の2種類です。

仕様を理解しないまま手順だけを機械的になぞると、ケースに書かれていない周辺の異常（レイアウト崩れや更新日時の不整合など）を見落とす原因になります。テストケースの期待結果を要件定義書や画面仕様書などと照合し、判断に迷う点は事前に確認しておきます。実行中も必要に応じてこれらの資料を参照しましょう。また、変更点の周辺は不具合が集中しやすいため、今回の改修差分も必ず把握しておきましょう。

3-2. テスト環境とデータが担当ケースの条件に合うか確認する

用意された端末・OS・ライセンス・データが担当するケースの条件に合い、利用できる状態かを確認します。あわせて本番環境との差異も確認します。テスト環境で外部システムとの連携処理がモック（固定値応答）に置き換わっていることを知らずに不具合起票すると、無駄な差し戻しが発生します。何が本番同等で何が代替モックなのかを事前に一覧で把握しておきましょう。

3-3. ツールの操作権限と判定・記録のルールを確認する

自分のアカウントでログインし、必要な起票・操作権限があることと、指定の保存先に記録を残せることを確認します。判定・取得・命名のルールが不明な場合は、開始前にテスト責任者へ確認します。

3-4. 実行を妨げる制約やブロッカーを確認する

ブロッカーとは、ログインできない不具合や必要データの未準備など、解消するまで対象のテストを進められない阻害要因です。

担当するケースに制約や未解消のブロッカーがないかを確かめ、実行できない場合は対応担当者と解消見込みをテスト責任者に問い合わせます。着手可能な別のケースがあれば、順序への影響を確認して進めます。

3-5. 担当ケースの実行順序と予定工数を確認する

自分が担当するケースの順序・優先順位・予定工数を確認します。順序を変える必要がある場合は、依存関係や制約への影響をテスト責任者と確認します。

テスト実行の進め方と結果の残し方

テスト実行では、毎日の作業開始時に当日の条件を確認し、そのうえで各ケースの操作・判定・記録を進めます。ここでは、日ごとの確認とケースごとの手順を分けて説明します。

4-1. 【毎日の作業開始時】当日の環境と未解消のブロッカーを確認する

毎日の作業開始時には、当日の対象バージョン、環境の稼働状況、データ・権限の変更、前日から持ち越したブロッカーを確認します。変更があれば、当日の実行順序や予定への影響をテスト責任者と確認します。

4-2. 【ケースごと】テストを実行する4つのステップ

各ケースは次の4ステップで進めます。共有された判定基準と記録方法に従い、担当者による判断のばらつきを防ぎましょう。

1. 実行するテストケースを選び、前提条件を確認する

決めた順序に従ってケースを選び、操作前にデータ・環境・アカウントなどの前提条件が揃っているか確認します。前のケースの操作でデータが変わる場合もあるため、その時点の状態を確かめます。不足がある場合は無理に進めず「ブロック」として記録・共有し、次の実行可能ケースを確認します。

2. 記載された手順に従って操作する

ショートカットなど手順から外れた操作や前のケースのキャッシュ残存は、結果が変わる原因になります。手順を忠実に実行し、記載のない想定外の挙動に出会った際は操作内容とともに記録を残して速やかに問い合わせます。

問い合わせは「この動作は仕様どおりですか」とYes/Noで回答できる形式にすると回答が早く返ります。また、担当ケースとは直接関係のない不審な挙動に気づいた場合も、自己判断で放置せずテスト責任者に共有しましょう。

3. 期待結果と実際の結果を比較して判定する

判定は期待結果と実際の挙動を突き合わせて行います。「正しく表示されること」など期待結果が曖昧で判断できない場合は、自己判断せず確認先へ問い合わせます。

判定・記録には、計画段階で定義し、実行前に共有したステータス区分を使います。次の表は区分と運用の一例です。

ステータス	定義	該当する状況	次に動く人と行動	進捗集計上の扱い
未実行	まだ着手していない	実行順序上、順番が来ていない	実行担当者が予定どおり消化する	残件に数える
合格	期待結果と実際の結果が一致した	手順を最後まで完了できた	次のケースへ進む	消化済みに数える
不合格	期待結果と実際の結果が一致しない	表示・挙動・データが仕様と異なる	実行担当者が起票し、開発者が修正する	消化済みかつ要再テストに数える
保留	正解が確定せず判定できない	期待結果が曖昧、仕様が未確定	仕様の確認先（開発・企画）が回答する	残件に数え、判断待ちとして内訳を出す
ブロック	外部要因で実行に着手できない	環境障害、データ未投入、権限未付与、先行不具合	環境担当者や開発者が阻害要因を解消する	残件に数え、環境待ちとして内訳を出す
対象外	今回の実行範囲から外すと決めた	該当機能が今回スコープ外、重複ケース	テスト責任者が除外を承認する	分母から除外し、除外理由を残す

特に「保留（判断待ち）」と「ブロック（環境・データ待ち）」を分けておくことで、次に誰が動くべきかが集計から即座に把握できます。不具合の疑いがある場合は別環境などでも再現確認を行い、重大な不具合はケース消化を待たずに即座に共有します。

4. 結果を記録し、定められた方法でエビデンスを取得する

結果はケースIDに対応させて記録します。エビデンスは、定められたタイミングで操作の前後や異常発生時に取得します。記録の基準は「第三者がそれを見て同じ判定に到達できるか」です。取得の実務ポイントは次の3点です。

• 取得すべき対象：判定根拠となる画面や出力、実行日時、実行環境（OS・端末・ブラウザ・ビルド番号）、必要に応じてログを残します。合格ケースの証跡も本番稼働後のトラブル発生時に、テスト時点の環境・条件・結果を確認する材料になります。
• 取得タイミング：操作前後の状態を対（ペア）で残すのが基本です（登録前と登録後の一覧など）。エラーなどの単発事象はその場で直ちに取得します。
• 保管と命名：ケースID・実行日・ステータスを含む命名規則でフォルダ管理し、証跡が散乱しないように徹底します。

不具合の報告方法と修正後の再テスト

不具合を報告する際は、開発者が現象を理解し、再現・原因調査に使える情報を残します。ここでは、不具合報告に書く項目、つまずきやすいパターン、修正後の再テストの使い分けを解説します。

5-1. 不具合報告に記載する項目

開発者が自力で再現できるよう、次の必須項目を記載します。

• 仕様との相違点：期待結果と実際の結果を対比して明記
• 再現手順：前提条件から通し番号で具体的に記述
• 再現頻度：常時か断続的かを記載（例：3回中1回発生）
• 再現しない条件：発生しなかった操作や別環境があれば明記
• 環境情報：ビルド番号、OS、端末、ブラウザ、利用権限
• 重大度：業務影響度と回避策の有無

特定のブラウザでは発生しないなど、再現しない条件も記載すると原因を絞り込む手がかりになります。

5-2. 不具合報告でつまずきやすい3つのパターン

以下は、不具合報告でつまずきやすい3つのパターンと、その防ぎ方です。

• 主観的な表現の混入：「おかしい」ではなく「仕様は更新日時順だが実際は登録順」のように事実と差分を記述します。
• 前提条件の省略：ログイン権限や事前マスタ登録などの前提条件を明記し、第三者が同じ条件で再現できるように手順を記述します。
• 環境情報の不足：報告フォーマットにビルド番号やOSなどの記入欄を用意し、報告時と調査時の環境の取り違えを防ぎます。

5-3. 【修正版の受領後】確認テストとリグレッションテストを使い分ける

修正版受領後の検証には性質の異なる2つのテストがあり、適切に使い分ける必要があります。

観点	確認テスト	リグレッションテスト（回帰テスト）
目的	修正が意図どおり効いたかを確かめる	修正が他の機能を壊していないかを確かめる
対象範囲	不合格になったケースそのもの	修正の影響が及ぶ機能の既存ケース
実施タイミング	修正版の受け入れ直後	確認テストの後、または修正をまとめた区切りごと
省略した場合のリスク	直っていない不具合をそのまま合格にする	修正で新たに生じた不具合を検出できない

リグレッションテストの範囲は修正内容（共通処理やデータ構造の変更など）に応じて決定します。影響範囲は開発者に確認し、優先度の高い基幹機能から重点的に検証します。

まとめ：テスト実行の手戻りを防ぐには準備と確認が重要

前工程では環境・データ・ルールを整え、実行担当者は「仕様書とテストケース」「環境とデータ」「操作権限と判定・記録のルール」「制約やブロッカー」「実行順序と予定工数」の5項目を開始前に確認します。

実行中は、毎日の作業開始時に変更点や未解消の問題を確認し、各ケースでは前提条件を確かめてから操作・判定・記録を進めます。担当するケースを受け取ったら、まずは5つの確認項目で不足がないか確かめましょう。

標準化と実行の両立に課題がある場合は、専門企業の活用も有効です。バルテスの「ソフトウェアテスト・品質向上サービス」では、ISO/IEC/IEEE 29119準拠の独自品質メソッド「QUINTEE」に基づき、計画策定から実行体制の構築まで一貫して支援しています。属人化やリソース不足に課題をお持ちの企業様は、ぜひお気軽にご相談ください。