ソフトウェアの品質を保証するためにはテストが欠かせません。そして、テストの中ではさまざまな「テストドキュメント」を扱うことになります。適切なテストドキュメントを作成・管理することで、テストの効率化や品質向上につながります。
本稿では、テストドキュメントの基本から主な種類、作成時のポイントまでお伝えします。これからテスト業務に携わる方や、テストエンジニアを目指す方は、ぜひ参考にしてください。
- もくじ
1.テストドキュメントとは?
1-1 テストドキュメントとは
テストドキュメントとは、ソフトウェアテストの各プロセスで作成される文書全般を指します。
テスト計画からテスト結果の報告まで、テストに関する情報を記録・整理します。
プロセスによって必要となるテストドキュメントは異なり、それぞれの役割も異なります。たとえば、「テスト計画書」は後続のテストプロセスの指針となりますが、「テスト報告書」は結果の報告や関係者への共有が主な目的です。
主要なテストドキュメントの種類を理解し、適切に作成・管理することが大切です。
1-2 テストドキュメントを作成する目的
テストドキュメントの種類にもよりますが、作成する主な目的は次の4つです。
テストプロセスの円滑な遂行
多くのテストドキュメントは、以降のテストプロセスの遂行に必要です。たとえば「テストケース」は、テストを実行するうえで欠かせません。
テスト情報の管理・共有
テストドキュメントによって進捗や結果、不具合といった情報を管理し、関係者間で共有できます。たとえば「テスト進捗管理表」は、テストの進捗を関係者間で管理・共有するために不可欠です。
テスト成果の可視化
テストドキュメントによって、テスト成果を可視化できます。たとえば「テストログ」は、テスト担当者のテスト実行結果を詳細に記録し、実施状況や結果を客観的に証明するものです。
テスト資産の蓄積・再利用
テストドキュメントはテスト資産として蓄積でき、再利用もできます。たとえば「テスト報告書」は、後に同様のテストを実施する際の参考資料になります。
2.テストドキュメント主な7つの種類
テストドキュメントには多くの種類があります。主なものは次の7種類です。
- テスト計画書
- テスト設計仕様書
- テストケース
- テスト進捗管理表
- テストログ
- 不具合報告書
- テスト報告書
それぞれの役割や内容について、簡単に見ていきましょう。
2-1 テスト計画書
「テスト計画書」は、これから実施するテストの指針をまとめるテストドキュメントです。テストの目的や対象範囲、使用するテスト技法、具体的なスケジュールなどを記載します。以降のテストプロセスを方向付け、テストの成否を左右する重要なものです。
テスト計画書の書き方について詳しくは、次の記事をご覧ください。
2-2 テスト設計仕様書
「テスト設計仕様書」は、テスト設計(テストケースの作成)に必要となる基本事項をまとめるテストドキュメントです。テスト計画書を踏まえ、具体的なテスト対象や観点、使用するテスト環境などを記載します。
テスト設計仕様書は、テストケースを作成するうえでの前提資料です。品質の高いテストケースを作成するためには、正確なテスト設計仕様書が欠かせません。テスト設計仕様書の書き方について詳しくは、次の記事をご覧ください。
2-3 テストケース
「テストケース」は、どのようにテストを実施するのかを具体化するテストドキュメントです。テストの観点や条件(テストデータなど)、実施手順、期待値などを1項目ずつ整理します。テスト担当者がテストを実施するうえで、テストケースは不可欠です。
テストケースに漏れや不備があれば、ソフトウェアに潜む問題を正しく検出できません。そのため、ソフトウェアの品質を確実に保証するためには、漏れのない正確なテストケースが必要です。テストケースの書き方について詳しくは、次の記事をご覧ください。
2-4 テスト進捗管理表
「テスト進捗管理表」は、実施しているテストの状況をリアルタイムに管理・共有するためのテストドキュメントです。テストケースの実施状況(OK・NG件数)、不具合の発生状況などを記録し、テストプロジェクトの関係者へテスト進捗を伝えます。
また、テストケースの消化率や不具合の発生件数をグラフで可視化することも一般的です。テスト進捗管理表は、テストプロジェクトの円滑な進行のために欠かせません。
2-5 テストログ
「テストログ」は、実施したテスト結果の詳細情報を時系列順に記録したテストドキュメントです。多くの場合、テストケースとワンセットで管理します。テストケースごとの実行結果や実行中に発生した問題、エラーの内容などを記録することが一般的です。
テストログはテスト実施の客観的なエビデンス(証拠)であり、テスト結果の分析や不具合の再現確認における貴重なデータでもあります。自動テストの場合は、テストツールの出力物をテストログとして利用することも多いです。
2-6 不具合報告書
「不具合報告書」は、テスト中に検出された不具合情報を記録・共有するためのテストドキュメントです。「欠陥レポート」「不具合管理表」「障害報告書」「バグレポート」など、呼び名は企業やチームによって変わります。
不具合報告書には、不具合の発生条件や再現手順、影響範囲、優先度などを記載し、開発チームや品質保証チームへ不具合状況を正確に伝えます。不具合の修正作業を効率化し、ソフトウェアの品質を向上させるために欠かせません。
2-7 テスト報告書
「テスト報告書」は、テストの実施結果を客観的にまとめ、関係者へ報告するためのテストドキュメントです。テストケースごとの結果(OK/NG)や検出された不具合を正確に記載します。「テストサマリレポート」として、より細分化することもあります。
テスト報告書は、テストプロセス全体の最終的な成果物です。また、ソフトウェアのリリース判断における重要な判断材料でもあります。テストの完了基準を満たしているか、残ったリスクは許容範囲内かなど、客観的な判断を下すために不可欠です。
3.テストドキュメントを作成する際の5つのポイント
テストドキュメントは多岐にわたりますが、作成時のポイントがいくつかあります。
テストドキュメントを作成する際のポイントとして、次の5点を押さえておきましょう。
- 各ドキュメントの目的と記載すべき情報を確認する
- トレーサビリティを確保する
- 継続的にメンテナンスする
- テンプレートを活用する
- チーム内でレビュー・共有する
3-1 各ドキュメントの目的と記載すべき情報を確認する
まず、作成前に各ドキュメントの目的と記載すべき情報を確認しましょう。目的と必要事項があいまいな状態で作成すると、情報の過不足が発生したり、焦点のずれた内容となったりしてしまいます。たとえばテストケースを作成する場合、テストの観点や条件、実施手順、期待値を記載する必要があります。何のためのテストドキュメントなのか、目的を果たすためには何が必要なのかを押さえたうえで、作成に取り掛かりましょう。
3-2 トレーサビリティを確保する
関連するテストドキュメントや開発ドキュメントの間で「トレーサビリティ(追跡可能性)」を確保しましょう。トレーサビリティとは、関連する文書・情報を明確に紐づけ、相互に情報をたどれる状態にすることです。たとえば、不具合報告書の各項目に該当するテストログのリンクを記載すれば、問題の発生源や影響範囲を素早く把握できます。テストドキュメントの価値を最大化するためには、トレーサビリティを確保する必要があります。
3-3 継続的にメンテナンスする
テストドキュメントは、テストプロジェクトの進行や状況変化に合わせて継続的にメンテナンスしましょう。メンテナンスを怠ると、実情とドキュメントの中身に食い違いが生じ、誤解を招きます。テスト進捗管理表のようにリアルタイムな情報共有に用いるドキュメントはもちろん、テスト報告書などの記録系ドキュメントも定期的なメンテナンスが必要です。テストドキュメントは、常に最新の状態を保つことを心がけましょう。
3-4 テンプレートを活用する
テストドキュメントを効率よく作成したい場合は、テンプレート(ひな型)を活用するのが効果的です。テンプレートを活用することで記載内容の抜け漏れや書き方の不統一、ミスを防げます。ただし、テンプレートを埋めるだけで終わらせず、プロジェクトの実情に合わせて最適化しましょう。
なお、当ブログ「Qbook」ではテスト設計仕様書や、テストマップなど、テストドキュメントテンプレートを提供しています。テストドキュメントの作成を効率化したい方は、ぜひダウンロードしてご活用ください。

3-5 チーム内でレビュー・共有する
作成したテストドキュメントは、必ずチーム内でレビュー・共有しましょう。
正確に作成したつもりでも、ケアレスミスや思わぬ誤解が潜んでいることがあります。テストドキュメントをチーム内で客観的にチェックし、こうした不備を解消することが大切です。
また、全チームメンバーに内容を把握してもらうことで認識のずれを防止でき、テストプロジェクトの円滑化につながります。
まとめ
テストドキュメントとは、ソフトウェアテストの各プロセスで作成される文書全般のことです。今回は、主なテストドキュメントとして次の7種類を紹介しました。
- テストケース
- テスト計画書
- テスト設計仕様書
- テスト進捗管理表
- テストログ
- 不具合報告書
- テスト報告書
テストドキュメントの種類や役割を理解することが、適切なテストプロセスを実現するための第一歩です。これからテストドキュメントを扱う方は、今回の内容をぜひ参考にしてください。