目的
テスト仕様書は、要件定義・基本設計・詳細設計の内容が「意図どおりに実装されているか」を検証するための設計書です。属人的なテストや抜け漏れを防ぎ、再現性のある品質保証（QA）を行うための基準になります。
テスト仕様書は、要件定義・基本設計・詳細設計の内容が「意図どおりに実装されているか」を検証するための設計書です。属人的なテストや抜け漏れを防ぎ、再現性のある品質保証（QA）を行うための基準になります。
本テンプレートの特徴
・単体／結合／総合（システム）テストの粒度に合わせて使えるExcel版
・テスト、前提条件、入力値、手順、期待結果、受入基準、判定、備考を網羅
・要件IDとのトレーサビリティとカバレッジ（網羅率）の管理を意識した構成
編集方針
編集部は多数の実務事例を参考に、現場でそのまま使える書式を目指して調整しています。社内開発／受託開発のいずれでも使いやすいよう、最小限で始めて拡張しやすい構成にしています。
zipファイルの中には、単体テスト、結合テスト、総合テストの項目を記述するためのテンプレートがあります。
エビデンスを貼ったり、不具合の詳細を記述するスペースはないので、別にファイルが必要になるかもしれません。
テスト仕様書のテンプレート
| ファイル名 | test_siyousyo.zip |
|---|---|
| 収録内容 | 単体テスト仕様書・結合テスト仕様書・総合テスト仕様書（各Excel） |
| ファイルタイプ | エクセル |
| 作成バージョン | Excel 2013 以降 |
| ファイルサイズ | 30.07 KB |
データ利用規約
・無料でご利用できますが著作権は放棄しておりません。
・当サイトのコンテンツを無断で複製・転載・転用することを禁止します。
・当サイトのデータの利用は、お客様ご自身の責任において行われるものとします。
・当サイトから入手されたデータにより発生したいかなる損害についても、一切責任を負いません。
・テンプレートのご利用によるトラブルの対応やサポートはしておりません。
・無料でご利用できますが著作権は放棄しておりません。
・当サイトのコンテンツを無断で複製・転載・転用することを禁止します。
・当サイトのデータの利用は、お客様ご自身の責任において行われるものとします。
・当サイトから入手されたデータにより発生したいかなる損害についても、一切責任を負いません。
・テンプレートのご利用によるトラブルの対応やサポートはしておりません。
テンプレートの使い方（最短導入手順）
- 要件定義書・設計書から要件IDを抽出して、テスト仕様書の「要件ID」「テスト観点」に紐づけます（トレーサビリティ）。
- テストレベル（単体／結合／総合）ごとにシートを選び、前提条件・データセット・手順・期待結果を記入します。
- 正常系・異常系・境界値・例外系を観点ごとに洗い出してテストケースを追加します。
- 判定結果・証跡の格納先（スクリーンショットやログのパス）を記録します。
- 未カバーの要件がないかカバレッジを確認し、ギャップを解消します。
テスト仕様書の書き方（記載項目と例）
- 要件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スプレッドシートでの運用は可能ですか？
可能です。複数名で同時編集する場合は変更履歴とフィルタビューを活用し、列幅・改行ルールをテンプレートに合わせて固定してください。
