テスト代行の成果物7種類一覧｜発注前に確認する形式・契約・検収基準

2026 8/09

2026年8月9日 2026年8月9日

テスト代行の成果物は、バグ票だけではありません。
計画書やテストケースなど、主に7種類の文書があります。

成果物の範囲を確かめずに見積もりを比べると、費用の差を正しく判断できません。
同じ名称でも、テスト代行会社ごとに内容や細かさが異なるためです。

この記事では、成果物の種類と発注前の確認事項を整理します。
契約、納品、保管、ベンダー選定に使えるチェック項目も紹介します。

テスト代行の成果物一覧｜主な7種類と役割

成果物は「計画・設計」「実行」「完了・振り返り」の3段階で整理できます。
まず、各文書の目的と受け取る時期を一覧で確認しましょう。

段階	成果物	主な役割	受け取る時期
計画・設計	テスト計画書	目的、範囲、体制、日程、前提条件を合意する	テスト開始前
	テスト観点表・仕様書	検証する観点を整理し、抜け漏れを防ぐ	設計完了時
	テストケース	手順、入力条件、期待結果を実行単位で示す	実行開始前
実行	バグ票	再現手順、発生環境、重要度などを開発側へ伝える	不具合の発見時
実行	実施結果報告書	実施率、合否件数、未実施項目、進捗を示す	定期報告時と完了時
完了・振り返り	カバレッジ／メトリクスレポート	検証範囲や品質指標を数値で示す	完了時
完了・振り返り	改善提案書	次回に向けた課題と改善策を示す	完了時

案件により、納品される種類や名称は変わります。
見積書では名称だけでなく、表にある役割と納品時期まで照合してください。

計画・設計段階｜実施範囲と判断基準を固める

計画・設計段階の成果物は、テスト全体の土台です。
テスト計画書には、対象と対象外、体制、日程、リスクを記載します。
これらを先に合意すれば、発注後の認識違いを防げます。

テスト観点表・仕様書は、「何を確かめるか」を機能や画面ごとに整理した文書です。
発注者が検証範囲を確認するためのチェックリストにもなります。

テストケースは、観点を手順、入力データ、期待結果まで具体化した文書です。
バグ票や実施結果とひも付ければ、検証の経緯をたどれます。

実行段階｜不具合と進捗を共有する

実行段階では、バグ票と実施結果報告書が判断材料になります。
バグ票には、再現手順、発生環境、重要度、優先度などが必要です。
必須項目があいまいだと、「再現しない」といった差し戻しが生じます。

記載項目を決める際は、バグ票の書き方｜再現手順が伝わる項目とテンプレートも参考にしてください。
実施結果報告書では、合否件数や未実施項目を確認します。
日程に対する進み具合も見れば、人員や公開日の判断に使えます。

完了・振り返り段階｜公開判断と次回の改善につなげる

完了時の成果物は、公開の判断と次回の改善に使います。
レポートには、機能別のカバレッジやバグ検出密度などを記載します。
対象範囲と算出方法も示されていれば、数値を判断に使えます。

改善提案書では、今回の課題と次回に取る行動を確認します。
単発の発注でも、成果物を次の品質改善へ引き継げます。

見積もり比較では成果物の範囲・形式・粒度をそろえる

見積もりは、同じ成果物を同じ条件で依頼した場合に限り比較できます。
テスト実行以外にも、計画、設計、分析、報告には工数がかかるためです。

「テスト報告書一式」という記載だけでは、納品内容を判断できません。
不具合件数の要約だけか、ケース別の結果や証跡まで含むかを確かめてください。

成果物が生まれる工程を把握すると、見積もりの根拠を確認しやすくなります。
全体の流れは、テスト代行の進め方｜依頼から納品までの流れで確認できます。

RFPや打ち合わせで確認する4項目

RFP（提案依頼書）や発注前の打ち合わせでは、次の4項目を確認します。
サンプルを見ながら合意すると、言葉だけの確認より認識をそろえやすくなります。

形式：自社指定のExcelや管理ツールを使えるか
粒度：正常系、異常系、境界値をどこまで扱うか
表記：用語や不具合の重要度を自社基準に合わせられるか
修正条件：想定と違う場合に、契約内で修正や再発行ができるか

特にテストケースは、会社ごとの差が出やすい成果物です。
機能ごとの件数ではなく、手順や期待結果の記載例まで確認してください。

準委任契約と請負契約では成果物の位置づけが異なる

成果物の扱いは、準委任契約と請負契約で異なります。
同じ文書名でも、契約上の役割と確認基準が変わる点に注意が必要です。

観点	準委任契約	請負契約
契約の中心	合意した業務の遂行	合意した仕事の完成
成果物の主な役割	業務の過程や結果を示す証跡	契約で定めた目的物
確認の基準	実施内容や稼働状況の妥当性	成果物の受け入れ基準
想定と違う場合	追加対応の範囲や費用を協議する	契約内容に基づき修正を協議する
形式の変更	業務中に調整しやすい	契約で定めた内容が基準になる

準委任契約では業務の証跡として確認する

準委任契約では、テスト代行会社は合意した業務の遂行に責任を負います。
成果物は、実施した作業や品質活動の妥当性を確認する材料です。

形式を調整しやすい一方で、文書の範囲や品質が自動で決まるわけではありません。
必要な成果物と報告内容は、業務範囲とあわせて明記しましょう。

請負契約では受け入れ基準まで明記する

請負契約では、契約で定めた成果物が仕事の完成を判断する対象になります。
成果物の一覧、形式、納品条件、受け入れ基準を契約書に明記してください。

条件があいまいだと、発注者とテスト代行会社で完成の認識がずれます。
修正の対象、期限、費用の扱いも、契約前に確認すると安心です。

納品方法と保管形式は契約終了後まで見据えて決める

成果物は、契約終了後も自社で閲覧し、再利用できる形で受け取りましょう。
専用ツールだけに保存すると、利用期限後に見られなくなる場合があります。

保管形式	利点	契約前の確認事項
Excel／Wordファイル	加工や社内形式への転記がしやすい	命名規則、版の管理方法、保管場所
プロジェクト管理ツール	進捗と状態をリアルタイムで共有できる	契約終了後の利用可否、出力形式
専用ポータル	報告書や指標を画面上で確認しやすい	閲覧期限、ダウンロード可否、出力範囲

ツールを使う場合は、データの出力方法を実際に確認してください。
添付画像やコメントなど、出力対象から外れる情報がないかも確かめます。

誰が、いつまで閲覧できるか
どの形式で一括出力できるか
証跡やコメントも出力できるか
自社の保管場所へ移す期限と担当者は誰か

受け取り方と保管ルールは、契約書か開始時の合意事項に残します。
担当者が変わっても、過去の判断とテスト内容を追える状態が理想です。

成果物の品質からテスト代行会社の実力を見極める

成果物を見ると、テスト設計と品質管理の力を判断できます。
発注前に、過去案件のサンプルや小規模な試行案件を確認しましょう。

確認項目	よい状態	注意が必要な状態
案件への適合	対象機能や仕様に沿っている	一般的な文言だけで構成されている
用語と形式	文書をまたいで統一されている	重要度や機能名の表記が揺れている
判断の根拠	観点や優先度の理由が読める	結果や数値だけが記載されている
バグ票	手順と条件から不具合を再現できる	情報が足りず、開発側が再現できない
改善提案	課題、対応、優先順位が具体的である	「テストを増やす」などの一般論にとどまる