目的
テスト仕様書は、要件定義・基本設計・詳細設計で決めた内容が「意図どおりに実装されているか」を確認するための設計書です。属人的なテストや抜け漏れを防ぎ、だれが見ても同じ基準で確認できる品質保証の土台になります。

本テンプレートの特徴
・単体/結合/総合(システム)テストの粒度に合わせて使えるExcel版
・テスト観点、前提条件、入力値、手順、期待結果、受入基準、判定、備考を整理しやすい構成
・要件IDとのトレーサビリティとカバレッジ(網羅率)の管理を意識した作り

編集方針
編集部では複数の実務例をもとに、現場でそのまま使いやすい書式になるよう調整しています。社内開発でも受託開発でも使いやすいよう、最初は最小限で始めて、必要に応じて広げやすい構成にしています。

テスト仕様書の例:単体テスト(関数・メソッド単位の検証)
テスト仕様書の例:結合テスト(モジュール間インターフェースの検証)
テスト仕様書の例:総合テスト(システム・業務フロー全体の検証)

zipファイルの中には、単体テスト・結合テスト・総合テストの項目を書き込めるテンプレートを収録しています。

エビデンスを直接貼り込んだり、不具合の詳細を長く残したりするための欄は大きく取っていないため、必要に応じて別ファイルや課題管理表とあわせて使うと運用しやすくなります。

テスト仕様書のテンプレート

ファイル名 test_siyousyo.zip
収録内容 単体テスト仕様書・結合テスト仕様書・総合テスト仕様書(各Excel)
ファイルタイプ エクセル
作成バージョン Excel 2013 以降
ファイルサイズ 30.07 KB
データ利用規約
・無料でご利用できますが著作権は放棄しておりません。
・当サイトのコンテンツを無断で複製・転載・転用することを禁止します。
・当サイトのデータの利用は、お客様ご自身の責任において行われるものとします。
・当サイトから入手されたデータにより発生したいかなる損害についても、一切責任を負いません。
・テンプレートのご利用によるトラブルの対応やサポートはしておりません。

テンプレートの使い方(最短導入手順)

  1. 要件定義書や設計書から要件IDを拾い出し、テスト仕様書の「要件ID」「テスト観点」にひも付けます。まずここをそろえておくと、あとで抜け漏れを見つけやすくなります。
  2. テストレベル(単体/結合/総合)ごとにシートを選び、前提条件・データセット・手順・期待結果を記入します。
  3. 正常系・異常系・境界値・例外系を観点ごとに洗い出し、必要なテストケースを追加します。
  4. 判定結果と、証跡の格納先(スクリーンショットやログのパスなど)を記録します。
  5. 未カバーの要件が残っていないかカバレッジを確認し、足りない部分を埋めます。

テスト仕様書の書き方(記載項目と例)

  • 要件ID/機能ID
    要件定義書・設計書と一致する番号で記載します。例:RQ-UI-023
  • テスト観点
    表示・入力・計算・バリデーション・エラーハンドリング・権限・パフォーマンス・セキュリティなど、何を確認するのかを明確にします
  • 前提条件
    認証状態、ロール、テストデータ、初期化手順、環境依存設定などを整理します
  • 入力値/操作
    境界値(min/max)、異常文字、桁数超過、NULL、同時操作など、実際に与える値や操作を具体的に書きます
  • 期待結果
    画面表示、APIレスポンス、DB更新、ログ出力、メッセージIDなど、判定できる形で記載します
  • 受入基準
    合否基準、許容誤差、応答時間(例:P95 2.0秒以内)などを明記します
  • 証跡
    スクリーンショット、HAR、DB差分、ログの保存場所などを記録します(別ファイル運用でも可)
  • 判定/備考
    OK/NG、再現条件、暫定対応、チケット番号などを残します

単体・結合・総合テストの違いと仕様書の使い分け

単体テスト(ユニット/コンポーネント)

最小単位(関数・メソッド・API単体)を対象に、ロジックやバリデーションを細かく確認します。モックやスタブを使う場合は、その前提条件も書いておくと後で見返しやすくなります。

結合テスト(インターフェース/API間)

モジュール間のデータ受け渡し、インターフェース仕様、エラーパスを中心に確認します。シーケンスどおりに動くか、例外時の整合が取れているかを見ていく場面で使います。

総合テスト(システム/業務シナリオ)

業務フロー全体を通して、権限、状態遷移、スループット、非機能要件(性能・セキュリティ・可用性)まで含めて確認します。現場ではここで想定外の抜けが見つかることも多いです。

テスト仕様書と他の「仕様書」との違い

要件定義書
実現すべき振る舞い・制約を定義する上流文書(何を作るか)

基本設計書/詳細設計書
構造・画面・API・データを設計する文書(どう作るか)

テスト仕様書
上記の要件・設計を検証するための具体的な手順と期待結果を定義する文書(正しく作れたか)

テスト計画書
体制・スコープ・日程・リスク・完了基準(出口基準)を定める上位計画

テスト報告書
実施結果・不具合統計・残課題・品質評価をまとめる成果物

環境・テストデータ・証跡のベストプラクティス

  • 環境情報:OS/ブラウザ/バージョン/端末/地域設定/タイムゾーン/APIエンドポイント
  • データ管理:初期化スクリプト、匿名化データ、再現データのバージョン付け
  • 証跡保管:スクリーンショット、ログ、SQL差分、API記録(例:HAR)の保管先を仕様書から参照できる形にしておく
  • 不具合管理:ISSUE番号やチケットURLを仕様書の備考欄に記載する

よくあるミスと再発防止チェック

チェックリスト(ミス防止)

  • 手順が曖昧で再現性がない(誰が実行しても同じ流れになる記述にします)
  • 期待結果が抽象的(数値・メッセージID・UI要素など具体値で定義します)
  • 境界値/異常系が不足(最小値・最大値・空・重複・タイムアウトを洗い出します)
  • 要件ID未紐づけで網羅率が見えない(要件とケースのマトリクスを維持します)
  • 証跡の保存場所が散らばる(仕様書から共通リポジトリのパスを参照できるようにします)

関連テンプレート

よくある質問(FAQ)

テスト仕様書とテストケースはどう違いますか?
テスト仕様書は、観点・前提条件・期待結果などを体系的に整理する設計書です。テストケースは、その仕様書に基づいて実行する個々の確認単位です。本テンプレートでは、同じシート内でまとめて管理しやすい構成にしています。
エビデンス(スクリーンショットやログ)はどこに貼りますか?
Excelのセルへ直接貼るとファイルが重くなりやすいため、共有ストレージなどへ保存し、仕様書の「証跡」欄に保存先パスやチケット番号を記載する方法が使いやすいです。
カバレッジはどのように管理しますか?
要件IDとテストケースを対応づけ、未カバーの要件が残らないように管理します。正常系・異常系・境界値の有無を列で持っておくと、抜けが見えやすくなります。
総合テストでは非機能要件も扱いますか?
はい。性能(応答時間・スループット)、セキュリティ(認可・入力検証)、可用性なども対象にします。期待結果や受入基準に、数値や条件をあらかじめ書いておくと判定しやすくなります。
Googleスプレッドシートでの運用は可能ですか?
可能です。複数名で同時に編集する場合は、変更履歴やフィルタビューを活用し、列幅や改行ルールを最初にそろえておくと運用しやすくなります。