テスト結果報告書の書き方｜そのまま使える章立てテンプレート

2026 8/13

2026年8月13日 2026年8月13日

「テストは終わったのに、報告書に何を書けばいいかわからない」。顧客や上長への提出期限が迫るなか、こう悩むPMやテストリーダーは少なくありません。社内にテンプレートも前例もない状況は、決して珍しいことではないのです。

この記事では、テスト結果報告書の書き方を、そのまま使える章立てテンプレート付きで解説します。数字の見せ方、終了基準との対応づけ、残存バグがある場合のリリース可否の示し方まで押さえれば、今日からドラフトを書き始められます。

テスト結果報告書とは｜テストサマリレポートとの関係

最初に、テスト結果報告書がどんな文書なのかを整理します。目的と読み手が定まれば、「何を書くべきか」は自然と絞られていきます。

誰が何のために読む文書なのか

テスト結果報告書の読み手は、テストの担当者ではありません。主な読み手は、顧客・上長・リリース判定者といった「リリースの意思決定をする人」です。

つまりこの文書の役割は、テストをやったことの証明ではありません。テスト結果報告書は「実施記録」ではなく、リリース可否を判断するための「判断材料」です。

読み手が知りたいことは、突き詰めると次の3点に集約されます。

計画したテストは、どこまで実施できたのか
どんな不具合が見つかり、どこまで解消したのか
残っている問題を踏まえて、リリースしてよいのか

この3つの問いに答える構成になっていれば、報告書として成立します。逆に、どれだけ詳細なデータを並べても、この問いに答えていなければ読み手は判断できません。

テストサマリレポート・テスト完了レポートとの関係

テストサマリレポート（test summary report）は、テスト技術者資格認定のJSTQBのシラバス・用語集で使われてきた、テスト結果を総括する文書の呼び名です。近年のFoundation Levelシラバスでは「テスト完了レポート」という呼び方に整理されていますが、指している文書は同じです。実務で「テスト結果報告書」「テスト完了報告書」と呼ばれる文書とも、ほぼ同じものと考えて構いません。

歴史的には、テスト文書の標準規格として長く参照されてきたIEEE 829が8種類のテストドキュメントを定義しており、その8番目が「テストサマリーレポート＝テスト結果の総括」でした（Lee Copeland『はじめて学ぶソフトウェアのテスト技法』）。IEEE 829自体は2013年にISO/IEC/IEEE 29119-3へ置き換えられた旧規格ですが、「テスト計画書に始まり、サマリレポートで締めくくる」という文書群の考え方は、現在の実務でも土台になっています。

テスト計画書とセットで意味を持つ文書

もうひとつ重要なのは、テスト結果報告書は単独では成立しないという点です。テスト計画書で「ここまでやったら終了とする」という終了基準を宣言し、報告書でその達成状況を答える。この対応関係があって初めて、報告書は説得力を持ちます。

例えるなら、テスト計画書が「試験問題」で、テスト結果報告書は「答案」です。問題と無関係な答案が評価されないのと同じで、計画と対応づかない報告は判断材料になりません。この対応づけの具体的な方法は、後の章で詳しく解説します。

テスト結果報告書の書き方がわかる章立てテンプレート

ここからが本題です。テスト結果報告書の書き方で最初につまずくのは「章立て」ですので、そのまま使えるテンプレートを先に示します。

そのまま使える章立てテンプレート

次の8章構成をベースにすれば、ほとんどの案件に対応できます。

章	章名	書く内容	分量目安
1	報告概要と結論	リリース可否の見解と根拠のサマリ	1ページ以内
2	テスト対象・目的	対象システム・バージョン・テストの目的	半ページ
3	テスト実施状況	期間・体制・テスト環境	半〜1ページ
4	テスト結果サマリ	消化率・合否件数などの実績数値	1ページ
5	不具合の集計と分析	検出数・重要度別内訳・対応状況・推移	1〜2ページ
6	終了基準の達成状況	計画で定めた基準と実績の対応表	1ページ
7	残存リスクとリリース可否の見解	未解消バグの影響・回避策・条件	1〜2ページ
8	添付資料	テストケース一覧・不具合管理表など	参照のみ

章の名称は組織に合わせて変えて構いません。ただし「結論」「実績数値」「終了基準との対応」「残存リスク」の4要素は、どんな案件でも省略しないでください。

一度この型で書けば、そのまま社内標準の雛形として使い回せます。

コピペで使えるテンプレート全文

章立て表を、そのまま文書に貼り付けられる形にしたものが次のテンプレートです。括弧内の記入ガイドを自案件の内容に差し替えて使ってください。

> 1. 報告概要と結論 > リリース可否の見解:（例: 条件付きでリリース可能と判断します） > 根拠の要約:（終了基準○項目中○項目達成。未達の項目と理由を2〜3行で） > 残存リスク:（未解消の不具合○件。詳細は第7章参照） > > 2. テスト対象・目的 > 対象:（システム名・対象機能・バージョン） > 目的:（このテストで何を確認するのか） > > 3. テスト実施状況 > 期間:（開始日〜終了日） > 体制:（役割と人数） > 環境:（テスト環境の構成。本番環境との差異があれば明記） > > 4. テスト結果サマリ > （計画ケース数・実施済み件数・消化率・合否件数を表で記載） > > 5. 不具合の集計と分析 > （重要度×対応状況のマトリクスと、週別の検出数推移を記載） > > 6. 終了基準の達成状況 > （計画時の終了基準と実績の対応表を、基準・実績・判定の3列で記載） > > 7. 残存リスクとリリース可否の見解 > （未解消バグごとに事象・重要度・発生条件・影響・回避策・対応予定を記載し、最後に可否の見解と条件を記載） > > 8. 添付資料 > （テストケース一覧・不具合管理表などへの参照）

最初に「結論」を書く——報告書は結末から読まれる

このテンプレートの最大のポイントは、第1章に「結論」を置いていることです。リリース判定会議の時間は限られており、判定者は結論から読みます。

テスト結果報告書は時系列で書くのではなく、「リリース可否の見解」を1ページ目に書くのが鉄則です。

1ページ目に書くのは、次の3点で十分です。

リリース可否の見解（例: 条件付きで可と判断）
根拠のサマリ（終了基準の達成状況を2〜3行で）
残存リスクの有無と、詳細を記載した章への参照

参考に、第1章の全文サンプルを示します（数値・内容はすべて説明用の架空の例です）。

> 1. 報告概要と結論 > 本報告書は、○○システム受注管理機能追加（バージョン2.1）のシステムテスト結果を報告するものです。 > リリース可否の見解: 下記の条件対応を前提に、リリース可能と判断します。 > 根拠: テスト計画書で定めた終了基準4項目のうち3項目を達成しました。未達の1項目（消化率98%）は、対象機能のリリース延期に伴う未実施10件によるもので、今回のリリース範囲には影響しません。 > 残存リスク: 未解消の不具合が5件あります（いずれも重要度・中以下、回避策あり）。詳細は第7章をご参照ください。 > 条件: 回避策の運用手順書への反映と、リリース後2週間以内の修正パッチ適用。

経緯や詳細データは2章以降に回します。「まず結論、根拠は後ろ」という順序にするだけで、読み手の負担は大きく下がります。

分量の相場観と小規模案件での縮め方

前例がないと「何ページ書けばいいのか」も不安になりますが、本体は数ページから10ページ程度が目安です。それ以上に膨らむ場合は、詳細データを添付資料に逃がしてください。

「判定者がその場で読む部分」を本体に、「あとから検証するための証跡」を添付に分けます。テストケースの全リストや不具合の全明細は、典型的な添付側の情報です。本体は「読ませる文書」、添付は「調べられる資料」と割り切ると、分量の迷いがなくなります。

また、テストケースが100件に満たないような小規模案件では、8章構成をそのまま維持する必要はありません。「対象・実施状況」「結果サマリと不具合集計」のように章を統合し、A4で2〜3枚に圧縮して構いません。ただしその場合も、結論・実績数値・終了基準との対応・残存リスクの4要素だけは、1枚にまとめるときでも削らないでください。

各章に何を書くか｜テスト計画書・終了基準との対応づけ

章立てが決まったら、次は中身です。ここでの核心はひとつだけです。テスト計画書で宣言した終了基準に対して、実績を1対1で対応づけること。これがテスト結果報告書の背骨になります。

終了基準と実績の対応表を作る

終了基準（exit criteria）とは、「ここまで達成できたらテストを終了してよい」と計画段階で決めておく条件のことです。報告書の第6章では、この基準と実績を対応表で示します。

次のような形式です（数値・内容はすべて説明用の架空の例です）。

終了基準（計画）	実績	判定
計画したテストケースの消化率100%	98%（490/500件、未実施10件）	×
重要度「高」の未解消バグ0件	0件	○
重要度「中」の未解消バグ3件以下	2件（回避策あり）	○
最終週の新規バグ検出が5件以下	3件	○

「計画→実績→差異→差異の理由」という型で書けば、報告に一本の筋が通ります。○×だけでなく、必ず数値を添えるのがポイントです。

終了基準そのものの決め方は計画段階のテーマですので、テスト計画の立て方を解説した記事を参考にしてください。

終了基準を決めていなかった場合の対処

計画時に終了基準を決めていなかったケースも、実務では珍しくありません。この場合も、報告時に基準を立てて実績と対比すれば、報告の型は保てます。ただし、結果を見てから都合よく基準を作ったと受け取られないよう、透明性の確保が必須条件になります。

事後に設定する基準は、一般的に使われる次の3つが出発点になります（内容は例です）。

計画したテストケースの消化率100%
重要度「高」の未解消バグ0件
最終週の新規バグ検出数が収束傾向にあること

そのうえで、次の2つの条件を必ず守ってください。

事後設定であることを報告書に明記する。対応表の前書きに「本基準はテスト計画時には定義しておらず、結果報告にあたり一般的な観点に基づき設定した」と正直に書きます
実績と対比する前に、基準の妥当性について判定者・顧客と合意する。メールや定例の場で基準案を先に提示し、「この観点で評価してよいか」を確認してから対比結果を報告します

顧客への説明には、たとえば次のような文面が使えます。

> テスト計画時に終了基準を明文化できておりませんでした。そのため、一般的に用いられる基準3項目を今回の結果報告にあたって設定いたしました。まず基準の妥当性をご確認いただき、そのうえで実績との対比をご報告いたします。次回以降の案件では、計画段階で終了基準を定義いたします。

隠さず、先に合意を取る。この2点を守れば、事後設定の基準でも判断材料としての信頼性を保てます。逆にこの手順を省くと、報告の中核である「計画と実績の対応づけ」そのものが疑われてしまいます。

計画からの逸脱・未実施項目の書き方

対応表を作ると、未達の項目や未実施のケースが見えてきます。ここで隠したくなる気持ちを抑えることが、信頼につながります。

未実施・逸脱項目は、次の3点セットで書きます。

範囲: 何を実施しなかったのか（例: 帳票印刷系の10ケース）
理由: なぜ実施しなかったのか（例: 対象機能のリリース延期）
影響: 未実施によるリスクはどの程度か

未達を正直に書いたうえで影響評価まで添えれば、それは「不備の告白」ではなく「リスクの報告」になります。逆に、未実施を伏せた報告書は、あとから発覚したときに報告全体の信頼を失わせます。

テスト環境・条件の記載

見落としがちなのが、テスト環境の記載です。テスト環境と本番環境に差異がある場合は、必ず明記してください。

OS・ミドルウェアのバージョン差異
データ量・データ種別の差異（本番相当データか、作成データか）
外部接続先（本物のAPIか、スタブか）

環境差異は「テストで確認できたことの限界」を意味します。つまり環境差異の記載は、後述する残存リスクの一部です。「決済は外部接続先の試験環境で確認しており、本番接続は未検証」といった一文があるだけで、読み手はリスクを正しく見積もれます。

数字の見せ方｜消化率・バグ件数・重要度別内訳の例

「バグは25件でした」と件数だけ報告しても、読み手は品質を判断できません。この章では、数字を「判断材料」に変える見せ方を解説します。使うのは消化率・重要度別内訳・検出数の推移の3点セットです。

なお、この章に登場する数値はすべて説明用の架空の例で、記事内では同一案件の数値として統一しています。

消化率は「分母」とセットで見せる

消化率（テスト消化率）は、計画したテストケースのうち実施済みの割合です。ここで重要なのは、率だけでなく分母と残の内訳を添えることです。

項目	値（架空の例）
計画ケース数	500件
実施済み	490件（消化率98%）
未実施	10件（帳票印刷系。対象機能のリリース延期のため）
実施済みのうち合格	485件
実施済みのうち不合格（未解消）	5件

「消化率98%」単体では、残り2%が致命的な領域かどうか分かりません。分母・残の内訳・理由まで示して、初めて判断材料になります。

不具合は重要度別内訳と対応状況で見せる

不具合件数も、総数ではなく「重要度×対応状況」のマトリクスで見せます。

重要度	検出	修正済み	対応中	対応見送り
高	4件	4件	0件	0件
中	12件	10件	1件	1件
低	9件	6件	0件	3件

（数値は架空の例。未解消は「対応中＋対応見送り」の5件で、前掲の不合格ケース5件に対応しています）

この表なら「重要度の高い不具合は解消済みで、残るのは影響の小さいもの」と一目で伝わります。高橋寿一氏『知識ゼロから学ぶソフトウェアテスト』でも、メトリクスは「自分たちがどれくらい品質を担保できているかの可視化」と位置づけられています。数字は集めることではなく、品質の状態を見せることが目的です。

検出数の推移で「収束」を示す

3つ目が、バグ検出数の推移です。テスト終盤に向けて新規検出が減っていれば、「不具合が出尽くしつつある＝収束」を示す根拠になります。

この分析で登場する「信頼度成長曲線」とは、不具合の累計検出数を時間軸にプロットした曲線（グラフ）そのものを指す言葉です。不具合が出尽くしてくると曲線の伸びが鈍り、横ばい（飽和）に近づきます。この飽和の形から収束を判断し、ゴンペルツ曲線などの数学モデルを当てはめて分析することもあります（布施昌弘ほか『ソフトウェアテストの教科書』）。

報告書では、そこまで厳密なモデル化は不要です。本来は累計の飽和を読む方法ですが、報告では週別の新規検出数が減っていく傾向を簡単な表やグラフで示す簡易版で十分です。

ただし誠実さのために一言添えたい注意点があります。検出数の減少は、担当者の休暇やテストの手薄化など、品質以外の要因でも起こります。「最終週も計画どおりの件数を実施したうえでの減少」のように、実施量とセットで示すと説得力が増します。

こうした品質メトリクスを深く学びたい場合は、IPA（情報処理推進機構）が公開しているソフトウェア開発分析データ集が公的な参考資料として役立ちます。

未解消バグが残る場合のリリース可否と残存リスクの書き方

報告書作成で最も悩ましいのが、未解消のバグが残っている状態でのリリース可否の書き方です。実務では、バグゼロでリリースを迎えられることはほとんどありません。

「バグゼロ」を待たない判断の考え方

テストの終了判定について、Boris Beizerは「いつ終了するかを判定するための、単一の、正当かつ合理的な判断基準は存在しない」と述べています（Lee Copeland『はじめて学ぶソフトウェアのテスト技法』で引用）。

つまり「バグゼロになったら終了」という単一基準は、そもそも現実的な判断軸ではありません。カバレッジや検出数の推移など複数の基準を組み合わせ、関係者の合意で判断するのが本来の姿です。

報告者の責務は「バグゼロ」を宣言することではなく、残存リスクを判断できる材料を尽くして示すことです。この前提に立つと、残存バグの報告は「弱みの開示」ではなく「報告書の中核」に変わります。

残存バグの書き方テンプレート

残存バグは、1件ごとに次の6項目で書きます。

事象: 何が起こるのか
重要度: 高・中・低などの区分
発生条件・頻度: どんな操作・状況で、どの程度の頻度で起こるか
業務への影響: 発生した場合に業務がどう困るか
回避策: 運用でのしのぎ方があるか
対応予定時期: いつ修正するか

記載例を1件分示します（内容は架空の例です）。

> 事象: 帳票のプレビュー画面で、明細が100行を超えるとレイアウトが崩れる > 重要度: 中 > 発生条件・頻度: 月末の大口取引データでのみ発生（月数回程度の想定） > 業務への影響: 印刷結果は正常のため、業務停止には至らない > 回避策: プレビューを経由せず直接印刷することで回避可能 > 対応予定時期: リリース後2週間以内のパッチで修正予定

この6項目が揃っていれば、判定者は「残してよいバグか」を自分で判断できます。なお、残存バグの重要度や対応順序の考え方は、バグ修正の優先順位付けプロセスを解説した記事で詳しく整理しています。

「条件付きリリース可」の見解の書き方

最後に、可否の見解の書き方です。白黒の二択で書く必要はありません。実務で最も使うのは「条件付き可」の型です。

> 終了基準の達成状況および残存不具合の影響評価から、以下の条件のもとでリリース可能と判断します。 > ・残存不具合5件の回避策を運用手順書に反映すること > ・リリース後2週間以内の修正パッチ適用を前提とすること

ポイントは、「可と判断する」の主語はあくまで報告者の見解であり、最終判断は判定者に委ねるという整理です。判断材料を尽くして示し、条件と対応計画を添える。ここまでできていれば、報告者としての責務は果たせています。

テスト結果報告書の書き方でよくあるNG例と改善例

ここまでの内容を、ありがちなNG例と改善例の対比で確認しましょう。自分の書いたドラフトのセルフチェックにも使えます。

NG例1「テストしました。バグは25件でした」

件数だけの報告は、判断材料がゼロです（件数は架空の例）。読み手には「25件は多いのか少ないのか」「残っているのか」が一切分かりません。

改善例: 「検出25件のうち、重要度・高の4件を含む20件は修正・再テスト済みです。残る5件はいずれも重要度・中以下で、回避策があります。詳細は残存リスク一覧をご覧ください」

件数に「重要度内訳」「対応状況」「残存の影響」を足すだけで、同じ事実が判断材料に変わります。

NG例2「問題ありません。リリース可能です」

今度は逆に、結論だけで根拠がないパターンです。順調な案件ほどやりがちですが、根拠のない結論は突っ込まれた瞬間に崩れます。

改善例: 「計画で定めた終了基準4項目のうち、消化率・重要度別残存数など全項目を達成したため、リリース可能と判断します（達成状況は第6章の対応表を参照）」

結論には、必ず終了基準の達成状況という「判断軸」を添えます。根拠の置き場所を示すだけでも、報告の信頼度は大きく変わります。

NG例3「詳細は不具合管理表を参照」

詳細をすべて添付に丸投げするパターンです。判定者に生データの解読を強いる報告書は、報告の役割を果たしていません。

改善例: 報告書本体には重要度別の集計表と残存バグの要約、そして結論を書く。不具合1件ごとの明細は添付の管理表への参照にとどめる。

「本体にサマリと結論、添付に明細」という分担を徹底します。なお、参照先となる不具合票そのものの品質も報告の説得力を左右します。1件ごとの書き方は、バグ報告書の書き方を解説した記事が参考になります。

NG表現を避ける言い換え早見表

最後に、曖昧表現を事実ベースに言い換える早見表です。『ソフトウェアテストの教科書』（布施昌弘ほか）では、テストドキュメントの記述は「誰が読んでも同じ解釈ができるレベル」の粒度が求められるとされています。

NG表現（曖昧）	OK表現（事実ベース）
たぶん大丈夫です	○○の条件で検証済みです
ほぼ完了しています	500件中490件実施済み、残10件は○○です（数値は架空の例）
大きな問題はありません	重要度・高の未解消バグは0件です
一部未確認です	○○機能の△△ケースが未実施です（理由: ○○）

報告書の説得力は、曖昧な形容詞を「数値と条件」に置き換えることで生まれます。ドラフト完成後に「たぶん」「ほぼ」「大きな」を検索して潰すだけでも、品質は一段上がります。

作成を効率化するコツ｜使い回せる型に育てる

テスト終了からリリース判定会議までの期間は短く、報告書の作成に何日もかけられません。この章では、次回以降も含めて作成を効率化する3つのコツを紹介します。

テスト実施中から報告書を書き始める
集計の仕組みを先に作る
今回の報告書を社内テンプレートに昇格させる

なお、前半の2つはテスト開始前・実施中の仕込みです。今回の提出期限が目前の方は、前章までのテンプレートでドラフトを仕上げたうえで、3つ目のコツだけ先に読んでください。

テスト実施中から報告書を書き始める

報告書は、テストが終わってから書き始めるものではありません。週次で集計している進捗（消化率・検出数・重要度別内訳）は、そのまま報告書の第4章・第5章の素材になります。

テスト実施中から報告書のドラフトに週次数値を転記しておけば、テスト終了時点で残る作業は「終了基準との対応づけ」と「結論・残存リスクの執筆」だけです。判定会議直前に徹夜で集計する事態を、段取りで防げます。

集計の仕組みを先に作る

集計に時間がかかる原因の多くは、バグ管理ツールの項目と報告書の集計軸のズレです。テスト開始前に、次の2点を合わせておきましょう。

バグ管理ツールの「重要度」区分を、報告書の内訳表と同じ区分にする
「ステータス」を、修正済み・対応中・対応見送りに集計できる区分にする

これだけで、重要度×対応状況のマトリクスがツールの集計機能で出せるようになります。どんな指標をどう設計するかは、テストメトリクスの設計ガイド記事で詳しく解説しています。

今回の報告書を社内テンプレートに昇格させる

最後のコツは、今回の成果物を一度きりで終わらせないことです。今回書いた報告書から数値を抜いた骨組みを、社内テンプレートとして保存することを強くおすすめします。

報告書の型は、一度作れば案件ごとにゼロから悩む必要がなくなります。次の案件では、テンプレートの数値と固有情報を差し替えるだけです。判定会議で受けた質問を反映して型を改訂していけば、報告書は組織の資産に育っていきます。

テスト結果報告書に関するよくある質問

テスト結果報告書についてよくある疑問に短く答えます。

テスト結果報告書は何ページくらいが適切ですか？

本体は数ページから10ページ程度が目安です。テストケースが100件に満たない小規模案件なら、A4で2〜3枚まで圧縮して構いません。本体には結論・実績数値・終了基準との対応・残存リスクを載せ、テストケース一覧などの証跡は添付に分けるのが基本です。

テスト完了報告書やテストエビデンスとの違いは何ですか？

テスト完了報告書は、テスト結果報告書と同じ文書の別名と考えて問題ありません。一方テストエビデンスは、スクリーンショットや実行ログなど、個々のテストを実施した証跡を指します。エビデンスは報告書の添付資料にあたるもので、報告書本体は証跡の束ではなく、リリース可否を判断するためのサマリと見解をまとめた文書です。