テストエビデンスとは？残す目的や記録項目、取得手順と記入例を解説
テスト結果を報告する際、「エビデンスを残してください」と言われても、具体的に何をどこまで記録すればよいか迷うことはありませんか？
テストエビデンスを残す基本は、「確認対象に応じた記録を選び、第三者が合否判定の根拠をたどれる形でテストケースと紐づけて保存すること」です。
結果欄に「OK」とだけ書いて証跡を残さないと、後からレビューする担当者や開発者に判定の妥当性が伝わりません。また、不具合が起きた際にも当時の状況や再現手順がわからず、余計な確認のやり取りやテストのやり直しといった手戻りにつながってしまいます。
この記事では、テストエビデンスの定義や残す目的、記録すべき基本項目、具体的な記入例、取得から保存までの手順、そして記録の手間を効率化する方法をわかりやすく解説します。
>>【新しくなったT-DASH】テスト自動化を、品質判断の根拠へ
テストエビデンスとは
テストエビデンスとは、テストを計画どおりに実施した事実と、その結果を裏付ける客観的な記録のことです。
画面キャプチャだけでなく、テストケース、実行結果の記録、欠陥レポートなどを対応付け、何をテストしてどう判定したのかをたどれるようにします。
JSTQBのFoundation Levelシラバスでは、テスト活動で作成する成果物をテストウェアとして整理し、仕様などのテストベース、テストケース、結果、検出した欠陥の間でトレーサビリティを保つ重要性を説明しています。本記事もこの考え方を踏まえ、実行時の記録を成果物と結び付けて残す方法を扱います。（出典：JSTQB「Foundation Levelシラバス Version 2023V4.0.J02」1.4.3・1.4.4、2024年改訂）
ソフトウェアテストでは、結果欄に「OK」と書くだけでは、どのような状態を見て合格と判断したのかが他の人には伝わりません。
まずは、エビデンスが指す具体的な記録の種類と、客観的な根拠が求められる理由を見ていきましょう。
エビデンスの意味と対象となる記録
テストエビデンスとは、テストの実施内容と結果を裏付ける「証拠」となる記録です。
「どのテストケースで何を確認したのか」「その結果、システムが実際にどう動作したのか」を、後から誰が見ても客観的に確かめられるように記録します。
テストエビデンスというと画面のスクリーンショットを思い浮かべる方が多いかもしれませんが、スクリーンショットはあくまで手段の一つにすぎません。
検証する内容や対象に応じて、次のようなさまざまな記録がエビデンスになります。
- 画面のスクリーンショット（UIの表示状態やレイアウトの確認）
- 実行ログやシステムログ（エラーの有無や内部処理の確認）
- APIのリクエストとレスポンス（送受信されたデータ内容やステータスコードの確認）
- 処理前後のデータベースやファイルの内容（データの更新や整合性の確認）
操作の流れや一瞬だけ表示される不具合を残す場合は、画面収録による動画も候補です。動画にはテストケースIDと確認箇所の再生時刻を添えると、第三者が判定の根拠を探しやすくなります。何を確かめるかに応じて、静止画・動画・ログなどを選びましょう。
「OK」の記入だけでなく根拠が必要な理由
テスト管理シートなどの結果欄に「OK」や「合格」とだけ書かれていても、第三者には「何を根拠に合格としたのか」がわかりません。
たとえば、テスト実施者が「問題なく動いた」と思い込んでいても、実は画面端のエラー表示を見落としていたり、確認すべき項目を取り違えていたりする可能性があります。
根拠となる客観的な記録が残っていなければ、その判定が正しかったのかを後から検証できません。
そのため、テストエビデンスを残す際は、テストケースで定義された「期待結果」と、操作時の「実際の結果」、そして判断材料となった「証跡」をセットにし、第三者が判定の経緯を正しくたどれる状態にしておくことが大切です。
テストエビデンスを残す目的
テストエビデンスを残す主な目的は、判定内容の確認、不具合発生時の原因調査、チーム内外への説明責任を果たすことの3点です。
1つ目は、テスト結果をレビューする担当者が、合否判定が妥当かどうかを確認するためです。記録があれば、テスト実施者の記憶や口頭の説明に頼ることなく、客観的な事実をもとにスムーズにレビューを進められます。
2つ目は、不具合が見つかった際や、リリース後に問題が発生した際の原因調査に役立てるためです。実行時の操作手順や入力データ、当時のログなどが残っていれば、開発者は不具合の再現手順や発生条件を正確に把握でき、迅速な原因究明につなげられます。
3つ目は、開発チームやクライアントに対して、計画どおりにテストを実施したことを証明するためです。プロジェクトの契約や取り決めによっては、エビデンスそのものが納品物として提出を求められるケースも珍しくありません。
ただし、必要となる記録の量や形式は、プロジェクトの規模や品質基準、顧客との合意内容によって異なります。
画像を過剰に保存すること自体を目的にするのではなく、「何を証明すべきか」という目的を意識し、事前に合意したルールに沿って残すことが重要です。
>>【新しくなったT-DASH】テスト自動化を、品質判断の根拠へ
エビデンスとして記録する内容と記入例
テストエビデンスを作成する際は、テストケース、実施条件、期待結果、実際の結果、判定、そして根拠となる記録を漏れなく対応付ける必要があります。
ここでは、基本となる記録項目を整理したうえで、対象に応じた記録の種類とタイミング、具体的な記入例を順に解説します。
基本となる記録項目
テストエビデンスに記録すべき基本的な情報は、次のとおりです。
- テストケースID・ケース名：どのテストを実施したかを特定する情報
- 実施日時・実施環境：テストを行った日時、検証環境のURL、端末やOS、対象のビルド番号など
- 入力値・操作内容：テスト時に実際に入力した値や、実行した操作手順
- 期待結果：仕様書に基づき、テストケースに定められた動作や画面表示
- 実際の結果：操作後にシステムが実際に示した動作や表示
- 判定：期待結果と実際の結果を比較した合否（OK／NGなど）
- 証跡の参照先：根拠となる画像ファイル名、ログの保存場所やリンク
なお、既存のテスト仕様書やテスト管理ツールにテストケースの詳細や前提条件が記載されている場合は、ケースIDやリンクで紐付ければ十分です。既存資料にある内容をエビデンスシートへ二重に書き写す必要はありません。
記録の種類と取得するタイミング
記録するエビデンスの種類と取得タイミングは、テストで検証したい内容や証明したい変化に合わせて選びます。
| 検証対象 | 記録の候補 | 取得するタイミング |
|---|---|---|
| 画面表示・UI | スクリーンショット、動画 | 表示を確認する操作の直後。変化を比べる場合は操作前後。動画は操作前から結果表示まで |
| API連携 | リクエストとレスポンス | リクエスト送信時とレスポンス受信時。両者を同じテストケースに対応付ける |
| バッチ処理・データ更新 | 実行ログ、処理前後のデータ | 実行前のデータを保存し、実行中のログと正常終了・異常終了後のデータを取得する |
取得するタイミングにも配慮が必要です。
たとえば「値が正しく変更されたこと」を証明したい場合、操作後の画面だけを記録しても、もともとどんな値だったのかがわからず変化を証明できません。このようなテストでは、操作前と操作後の両方の状態を記録しておく必要があります。
すべてのテストケースで機械的に同じ枚数の画面を保存するのではなく、「期待結果と比較するために、どの時点のどんな記録が必要か」を判断して取得しましょう。
テストエビデンスの記入例
ECサイトの「カートの数量変更」を題材としたテストエビデンスの記入例を紹介します。
| 項目 | 記録内容 |
|---|---|
| テストケースID | TC001 |
| テストケース名 | カートの数量変更 |
| 実施日時 | 2026年09月14日 10:30（※実施時の実際の日時を記録） |
| 実施環境 | 検証環境 / ビルドv1.2.0（※URLやOS、端末情報などを記録） |
| 入力・操作手順 | カート画面で商品の数量を1から2へ変更し、「更新」ボタンを押下する |
| 期待結果 | 数量欄に「2」と表示されること |
| 実際の結果 | 数量2を確認 |
| 判定 | OK |
| 証跡ファイル | TC001_操作前.png、TC001_操作後.png |
※架空の画面を用いた記入例です。実際のテスト実施結果ではありません。
この記入例では、操作前と操作後の画像をテストケース「TC001」に紐付け、数量が1から2へ更新されたことが画像上で明確に追えるようにしています。
提出時には、画像内の数量表示部分を赤枠で囲むなど、確認した箇所がひと目でわかる工夫をするとさらに伝わりやすくなります。なお、実施日時や環境には、テストを実施した実際の日時や接続先URL、ビルド番号などの実測値を記録します。
注意点として、このテストケースで確認できているのは、あくまで「数量欄の表示が2になったこと」のみです。
もし「合計金額が再計算されること」や「データの保存状態」まで検証するのであれば、それぞれに対応した期待結果と別の確認記録を用意しなければなりません。1枚の画像で確かめられる範囲を超えて、他の動作までまとめて合格と判定しないよう注意してください。
>>【新しくなったT-DASH】テスト自動化を、品質判断の根拠へ
テストエビデンスを取得・保存する手順
テストエビデンスを確実に残すには、テスト実施前から提出までの流れを整えておくことが大切です。
「事前確認」「実行中の取得」「判定と紐付け保存」「提出前レビュー」という4つのステップに沿って進めることで、証跡の取り忘れや判定根拠の不足を防げます。
1. 取得対象と保存形式を事前に確認する
エビデンスの記録方針や保存・提出のルールは、テスト計画の段階で関係者と合意しておきます。テストを実施する担当者は、作業に入る前に決定済みのルールをしっかり確認しておきましょう。
具体的には、期待結果を確認するために、画面のスクリーンショットや動画、サーバーログ、データベース出力のどれを残すのかを確認します。操作前の状態を撮る必要があるかなど、手順書で指定された取得タイミングも把握しておきましょう。不明点があれば自己判断せず、計画や手順書の作成担当者に確認してください。
また、保存先フォルダの階層やファイル命名規則、提出フォーマットも事前に把握しておくことで、後からの撮り直しやファイルの再配置といった手戻りを防ぐことができます。
2. テストを実行しながら記録を取得・確認する
テストの手順に沿って、必要なタイミングでその都度エビデンスを取得します。
操作を進めるなかで、テスト手順書と異なる操作を行ったり、予期しないエラーや表示崩れが発生したりした場合は、その状況もそのまま記録に残すことが重要です。期待どおりの結果にならないからといって、画面を再読み込みしたり操作をやり直したりして、都合のよい画面だけを撮ることは避けてください。
また、画像やログを取得した直後にはファイルを一度開き、判定に必要な箇所が明瞭に写っているか、文字が潰れて読めなくなっていないかを確認しましょう。
すべてのテストが完了した後に画像の不備に気づくと、同じ状態を再現して撮り直すために多大な時間を費やすことになります。
3. 判定を記録しテストケースと紐付けて保存する
テスト結果が出たら、期待結果と実際の結果を突き合わせて合否判定を記録し、取得したエビデンスをテストケースと確実に紐付けて保存します。
後からレビューする担当者や開発者が迷わず確認できるよう、ファイル名や保存場所には規則性を持たせましょう。
たとえば、「TC001_操作後.png」のようにテストケースIDと取得タイミングがわかる名前を付け、結果管理シートの該当欄にファイル名やリンクを記載すると、対象の記録をスムーズにたどることができます。
※上記のファイル名は一例です。プロジェクトで定められた命名規則がある場合は、必ずその指定に従って保存してください。
4. 第三者に伝わるか提出前に見直す
エビデンスを提出・共有する前に、記録を見た第三者が操作内容や判定の妥当性を迷わず理解できるかを見直します。
確認すべきポイントは、対象のテストケースとエビデンスが正しく対応しているか、期待結果と照らし合わせるべき注目箇所が明確に示されているか、といった点です。単にファイルが存在しているかだけでなく、判定根拠として過不足がないかを確かめましょう。
同時に、テストに関係のない不要な画面や、テスト用ではない個人情報・機密情報が意図せず写り込んでいないかも確認します。不要な情報はマスキングするなどして適切に取り除きつつ、判定に必要な情報はしっかり残した状態で提出します。
エビデンスの取得・整理にかかる手間を減らす方法
テストエビデンスの作成は重要な作業ですが、画面キャプチャの切り貼りやファイルの整理に過度な時間がかかると、本来のテスト業務を圧迫してしまいます。
品質を落とさずに作業負担を減らすには、「ルールの共通化」「キャプチャツールの活用」「自動化の導入」という3つのアプローチが効果的です。
1. フォーマットや保存ルールを共通化する
プロジェクト内で記録項目や保存ルールを共通化しておくことは、作業効率の向上に直結します。
エビデンスの記入フォーマット、ファイルの命名規則、保存先フォルダの階層構造などをあらかじめ統一しておけば、テスト担当者がケースごとに書式や置き場所に悩む時間をなくせます。
スプレッドシートやExcelで結果を管理する場合も、前述の記入例などを共通のテンプレートにし、テストケースごとに判定と参照先を追記する運用にしておくと手戻りを防げます。
ただし、記録項目を細かく増やしすぎると、かえって記録作業そのものが目的化して負担が増えてしまいます。テストケースとの対応関係が維持でき、第三者が判定根拠をたどれる「必要最小限のルール」に留めることが大切です。
2. 画面キャプチャツールを活用する
画面キャプチャの取得や保存作業を効率化するには、まずOS標準の機能を確認しましょう。
Windows 11の「Snipping Tool」は、［Windowsロゴ］キー＋［Shift］＋［S］キーで画面の切り取りを開始できます。撮影した画像の自動保存にも対応し、保存先や自動保存の動作は設定から変更できます。（出典：Microsoft「Snipping Tool を使ってスクリーン ショットをキャプチャする」）
Macでは、［Shift］＋［Command］＋［5］キーで「スクリーンショット」を開き、画面全体や一部の撮影、動画の収録を選べます。「オプション」から保存先も指定できます。（出典：Apple「Macでスクリーンショットを撮影する/画面を収録する」）
こうしたツールを取り入れることでキャプチャや保存の手間を減らせますが、判定に必要な情報が画面に正しく写っているかどうかの確認まで自動で済むわけではありません。記録内容の確認は、必ず人の目でしっかり行いましょう。
3. 記録の取得やテスト実行を自動化する
同じテストを繰り返し実行する回帰テストなどでは、記録の取得やテスト実行自体の自動化を検討することで、大きな作業負担の軽減につながります。
テストの実行に合わせて画面キャプチャを自動取得したり、ログを保存して実行結果をレポートとして出力させたりすることで、人手による撮影や貼り付け、ファイル整理の手間を大幅に省けます。
テスト自動化ツールの一つである「T-DASH」は、プログラミング不要のノーコードでテストを作成できるツールです。
T-DASHではスケジュール実行と分析レポートを利用でき、継続的にテストを実行した結果を品質判断の材料として活用できます。画面やログの取得・保管要件とは分けて、自社で必要な記録を残せるかを導入時にぜひご確認ください。
ただし、テストや記録を自動化する場合でも、「何を期待結果とし、どの記録を合格の根拠とするか」という事前設計や、出力された証拠が十分であるかの確認は人手で行う必要があります。自動化によって取得件数が増えたことだけで、テストや記録の品質が上がったとは判断しないよう留意しましょう。
ノーコードテスト自動化ツール「T-DASH」について概要を知りたい方には、無料ダウンロード資料をご用意しております。
▶ テスト自動化ツール「T-DASH」サービス紹介資料をダウンロードする
まとめ｜合否の根拠が第三者に伝わる記録を残そう
テストエビデンスとは、テストを実施した事実と実際の結果を示し、その合否判定が妥当である根拠を第三者が客観的に確認できるようにするための記録です。
適切なエビデンスを残すには、画面キャプチャだけでなくログやデータなど検証対象に合わせた証拠を選び、テストケースや期待結果と正確に対応付けて保存することが欠かせません。
記録フォーマットの共通化や各種キャプチャツール、テスト自動化ツールを状況に応じて取り入れることで、第三者への伝わりやすさを維持しながら、取得や整理にかかる負担を効率よく軽減できます。
まずは現在担当しているテストケースの中から1件を選び、「その合否を他者に説明するためにどのような画面やログが必要か」をチームのルールと照らし合わせて確認することから始めてみましょう。
>>【新しくなったT-DASH】テスト自動化を、品質判断の根拠へ
