--- title: "テスト仕様書とは？書き方とテストケースの項目・発注者がレビューで見る観点" url: "https://www.issoh.co.jp/column/details/19412/" published: 2026-11-06 updated: 2026-11-06 categories: ["Webシステム"] publisher: "株式会社一創" --- # テスト仕様書とは？書き方とテストケースの項目・発注者がレビューで見る観点 テスト仕様書は、完成したシステムが要件どおりに動くかを確かめるために、テストケースごとの前提条件・手順・期待結果をまとめた文書です。本記事では、テスト計画書やテストケースとの違い、記載項目と書き方の手順、同値分割法や境界値分析といったテスト技法を順に整理します。後半では、発注者がテスト仕様書を検収の物差しとして読むときのレビュー観点と、IPAのモデル契約にある「検査仕様書」の扱いまで踏み込みます。 ## まとめ：テスト仕様書は合格の条件を発注者と開発会社で先に固める文書 テスト仕様書の価値は、テストを実施した記録よりも「何が確認できれば合格か」を実施前に合意できる点にあります。テストケースは、ID・前提条件・手順・入力値・期待結果・実施結果の列を最低限そろえ、期待結果を誰が読んでも同じ判定になる具体の値で書きます。 発注者が全件を読む必要はありません。要件との対応表で確認されていない要件が無いか、期待結果に「正しく表示される」のような曖昧な書き方が残っていないか、異常系のケースが入っているかの3点を見れば、検収で揉める箇所の大半を事前に潰せます。受入テストの基準は発注者側が主導して決め、細部の作成は開発会社に支援を依頼する分担が現実的です。 ## テスト仕様書とは何か｜テスト計画書・テストケースとの違いと作成工程 テスト仕様書という名称は業界の慣用で、規格上は呼び名が分かれます。まず位置づけと、ほかのテスト文書との境目を押さえます。 ### テスト仕様書の定義と役割｜要件ごとに確認項目と期待結果を固める文書 テスト仕様書は、要件定義書や設計書に書かれた内容を「どの条件で、何を入力し、どうなれば正しいか」に分解した文書です。設計書が作るものを定義するのに対し、テスト仕様書は作ったものの確かめ方を定義します。 JSTQBの[Foundation Levelシラバス（V4.0・2023年4月12日版）](https://jstqb.jp/dl/JSTQB-SyllabusFoundation%5FVersionV40.J02.pdf)では、テスト分析を「何をテストするか」、テスト設計を「どのようにテストするか」に答える活動と説明しています。テスト設計の作業成果物として挙げられているのが、優先順位を付けたテストケース・テストデータ要件・テスト環境要件です。国内の現場でテスト仕様書と呼ぶ文書は、おおむねこのテスト設計とテスト実装の成果物を1冊にまとめたものに当たります。 仕様書全般の種類や設計書との違いは[仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点](https://www.issoh.co.jp/column/details/13200/)で整理しています。本記事はその中のテスト仕様書だけを掘り下げます。 ### テスト計画書・テストケース・テスト報告書との違いを役割で整理 テスト関連の文書は名前が似ているため、発注時の成果物一覧で取り違えが起きやすい領域です。役割と作るタイミングで並べると次のようになります。 | 文書 | 答える問い | 作る時期 | | ------ | ------------- | --------- | | テスト計画書 | 範囲・体制・日程・終了基準 | テスト工程の開始前 | | テスト仕様書 | 何をどう確かめれば合格か | 設計の確定後 | | テストケース | 1件ごとの入力と期待結果 | 仕様書の中に含める | | テスト報告書 | 結果・不具合・残存リスク | テスト完了時 | テストケースは独立した文書ではなく、テスト仕様書を構成する1行1行を指す呼び方です。発注の見積書に「テスト仕様書一式」とだけ書かれている場合は、テストケースの件数と、実施結果まで記入して納品されるのかを確認しておくと後の認識違いを防げます。 ### テストレベル別に変わる作成者と粒度｜単体から受入テストまでの分担 テスト仕様書は工程ごとに別の冊子になり、作成者と細かさが変わります。単体テストは開発者がモジュール単位で作り、そこに並ぶのはコードの分岐を網羅する細かいケースです。結合テストとシステムテストは開発会社のテスト担当が、画面遷移や外部システム連携、性能などの観点で作成します。 受入テストだけは性質が異なります。JSTQBシラバスでも、受け入れテストはユーザーのビジネスニーズを満たしているかの妥当性確認であり、想定ユーザーが実施するのが理想とされています。業務の流れに沿ったシナリオで書くため、発注者の業務担当が中身を決めないと成り立ちません。受入テストそのものの進め方と合否基準は[受入テスト（UAT）とは？進め方と合否基準・システムテストとの違い](https://www.issoh.co.jp/column/details/19414/)で整理しています。工程全体の流れは[システム開発のテスト工程とは？種類・流れとV字モデル](https://www.issoh.co.jp/column/details/13445/)で解説しています。 ## テスト仕様書の書き方｜テストケースの記載項目とテンプレートの列構成 書式はExcelでもテスト管理ツールでも構いません。差が出るのは列の選び方と、期待結果の書き方です。 ### テストケースに書く10項目｜ID・前提条件・手順・期待結果・実施結果 テンプレートの列は、次の10項目をそろえておけば実施・不具合報告・再テストまで1枚で回せます。 | 列 | 書く内容 | | ------- | --------------- | | ケースID | 不具合票から参照する一意の番号 | | 要件ID | 対応する要件定義書の番号 | | 大・中分類 | 機能名と画面名 | | テスト観点 | 正常系・異常系・境界値など | | 前提条件 | ログイン状態や登録済みデータ | | 手順 | 操作を番号付きで1動作ずつ | | 入力値 | 具体の値（8文字の英数字など） | | 期待結果 | 画面表示・DBの値・メール送信 | | 実施結果 | OK・NG・保留と不具合票番号 | | 実施日・実施者 | 再テスト時の追跡用 | 実務で省かれやすく、後で困るのは「要件ID」の列です。この列が無いと、どの要件が一度もテストされていないかを数えられません。表紙側には版数・作成者・承認者・改訂履歴を置き、テスト環境（URL、ブラウザとその版、テスト用アカウント）を1ページにまとめておきます。 ### テスト仕様書を作る5つの手順｜要件の読み込みからレビュー承認まで 作成は、要件と設計を読み込む作業から始まります。手順は次のとおりです。 1. 要件定義書と設計書を読み、テスト対象の機能と対象外を一覧にする 2. 機能ごとにテスト観点（正常系・異常系・境界値・権限・性能）を洗い出す 3. 観点をテスト技法でテストケースに展開し、入力値と期待結果を書く 4. 要件IDとの対応を確認し、ケースが1件も無い要件を埋める 5. 開発会社内のレビューを経て、発注者の確認と承認を受ける 1の段階は、要件定義書に残っている曖昧な記述が見つかることも多い段階です。テスト仕様書の作成は、要件の書き漏れを見つける最後の機会でもあるので、疑問点は質問票にして発注者へ返します。要件定義書側の記載項目は[要件定義書の書き方：章立てサンプル・記載項目・レビュー観点](https://www.issoh.co.jp/column/details/12849/)が参考になります。 ### テストケースの書き方の例｜会員登録のパスワード欄を期待結果まで書く 「パスワードは8文字以上64文字以下」という要件を例に、テストケースを書き起こします。 | ID | 入力値 | 期待結果 | | ------ | ------- | ---------------------- | | TC-012 | 英数字7文字 | 8文字以上で入力のエラーを表示し登録しない | | TC-013 | 英数字8文字 | 登録完了画面へ遷移し確認メールを送信 | | TC-014 | 英数字64文字 | 登録完了画面へ遷移し確認メールを送信 | | TC-015 | 英数字65文字 | 64文字以下で入力のエラーを表示し登録しない | 期待結果の欄に「エラーになること」とだけ書くと、どの文言が出れば正しいのか、データが登録されていないことまで確認するのかが実施者ごとに割れます。表示される文言・遷移先・登録されないことの3点まで書き切るのが目安です。 ## テストケースを漏れなく作るテスト技法｜同値分割・境界値と組合せの整理 テストケースの数を勘で決めると、似たケースばかり増えて肝心の境目が抜けます。JSTQBシラバスの4.2節が挙げるブラックボックステスト技法は、同値分割法・境界値分析・デシジョンテーブルテスト・状態遷移テストの4つです。 ### 同値分割法と境界値分析｜2値と3値の違いで検出できる欠陥が変わる 同値分割法は、同じ処理をされる入力をひとまとまりのグループ（同値パーティション）に分け、各グループから代表値を1つ選ぶ技法です。パスワードの例なら「7文字以下」「8〜64文字」「65文字以上」の3グループになります。 境界値分析は、そのグループの境目を集中的に確かめる技法です。シラバスは2値BVAと3値BVAの2種類を扱っています。下限側で試す値は、2値なら7と8、3値なら7・8・9という組み合わせです。シラバスには、「x≦10」と書くべき判定を「x=10」と誤って実装した場合、2値の10と11では見つからず、3値で加わる9で初めて検出できる例が載っています。金額計算や在庫数のように、境目の誤りが業務上の損失に直結する入力欄は3値で書く、と決めておくと判断に迷いません。 ### デシジョンテーブルと状態遷移テスト｜条件の組合せと状態の漏れ対策 デシジョンテーブルは、複数の条件の組み合わせごとに結果を表で整理する技法です。「会員ランク×購入金額×クーポン有無」で送料と割引が変わるような業務ルールでは、組み合わせを表に書き出すだけで仕様の抜けが見つかります。条件が増えると列が爆発するため、シラバスも最小化したテーブルやリスクに応じた絞り込みに触れています。 状態遷移テストは、申請・差戻し・承認・取消のように状態を持つ機能に向きます。状態遷移図に加えて状態表を作ると、「承認済みの申請を取り消せるか」のような本来は起きてはいけない遷移まで洗い出せます。ワークフローや予約管理の業務システムでは、この無効な遷移の確認が漏れやすいところです。 ## 発注者がテスト仕様書をレビューする観点｜検収の物差しとして読む方法 ここからは発注者側の話です。テスト仕様書は開発会社の内部資料と思われがちですが、受入テストと検収の基準になる以上、発注者が中身を確認しないまま承認すると、合否の判断を開発会社に預けることになります。 ### 要件とテストケースの対応表｜トレーサビリティで確認漏れの要件を探す 最初に見るのは、要件ごとのテストケース件数です。JSTQBシラバスは、テストケースと要件のトレーサビリティによって要件がテストでカバーされていることを検証できると説明しています。要件IDの列を集計して件数が0の要件があれば、その機能は誰も確かめないまま納品されることになります。 件数の偏りも、テストケースの配分を確認する手がかりです。要件の多い受注処理に20件しかなく、設定画面に80件あるような配分なら、作りやすい箇所からケースを書いた可能性があります。要件から設計・実装・テストまでを紐付ける実装手順は[ITのトレーサビリティとは？要件から設計・実装・テストを紐付ける実装手順](https://www.issoh.co.jp/tech/details/16816/)で詳しく扱っています。 ### 期待結果の曖昧さと異常系の比率｜合否が人で割れる書き方を差し戻す 次に、期待結果の欄を拾い読みします。「正しく表示される」「正常に処理される」「問題ないこと」が並んでいたら差し戻してください。何をもって正しいとするかが書かれていないケースは、実施者の解釈で合格にできてしまいます。 もう1点は異常系の割合です。必須項目の未入力、桁あふれ、二重送信、権限の無いユーザーによる操作、外部APIの応答なしといったケースが正常系に比べて極端に少ない仕様書は、リリース後の問い合わせが増える傾向にあります。発注者の業務担当は、過去に現場で実際に起きた入力ミスや例外処理を挙げて、ケースへの追加を依頼すると効果が出ます。 ### モデル契約の検査仕様書｜発注者が作成し開発会社が承認する検収基準 IPAと経済産業省がまとめた[情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)は、受入テストに当たる文書を「検査仕様書」と呼び、作成主体を発注者側に置いています。第27条では、発注者（甲）が開発会社（乙）と協議のうえ、テスト項目・テストデータ・テスト方法・テスト期間を定めた検査仕様書を作成し、乙がシステム仕様書との適合を点検して承認する流れです。作成の支援は個別契約で乙に委託できます。 第28条では、甲が検査期間内に検査仕様書に基づいて検査し、合格なら検査合格書を交付します。期間内に書面で具体的な理由を示して異議を述べなければ合格とみなされる点は、発注者が見落としやすい条文です。つまり検査仕様書が薄いと、確認しきれないまま期間が過ぎて検収が成立します。検収の実務と日付の扱いは[検収とは？検収日の意味・受入検査との違い](https://www.issoh.co.jp/column/details/17274/)を参照してください。 社内に受入テストの基準を書ける担当がいない場合は、要件定義の段階から発注者側に立って検査の基準づくりを支える体制を用意する方法があります。一創の[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)では、要件定義書の整備から受入基準のレビューまでを発注者側で支援しています。 ### テスト仕様書を作り込みすぎる失敗｜細かさより更新され続ける運用 反対の失敗もあります。全画面・全項目に網羅的なケースを求めて数千件の仕様書を作らせると、仕様変更のたびに更新が追いつかなくなり、実施結果と中身が食い違った文書だけが残ります。 判断の基準ははっきりしています。受入テストの仕様書は、業務の主要シナリオと金額・権限・外部連携に関わるケースに絞り、数百件以内に収めます。画面の細かな表示確認まで発注者の仕様書に入れる必要はありません。それは開発会社のシステムテストの領分です。改修が続くシステムでは、手作業のケースを増やすより、変更のたびに流す回帰テストを自動化した方が費用対効果は上がります。範囲の選び方は[リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断](https://www.issoh.co.jp/tech/details/13008/)にまとめています。 ## テスト仕様書の作成者・文書の違い・管理方法についてよくある質問 テスト仕様書の作成やレビューについて、発注者・開発担当の双方から寄せられやすい質問に回答します。 ### テスト仕様書は誰が作成するのですか？ 単体・結合・システムテストの仕様書は開発会社が作成します。受入テストの仕様書は、IPAのモデル契約では発注者が作成し開発会社が点検・承認する形で、作成の支援を開発会社へ委託することも可能です。実際には開発会社が叩き台を書き、発注者の業務担当がシナリオと期待結果を確認して承認する進め方が多く見られます。誰が最終的に承認するかは契約時に決めておきます。 ### テスト仕様書とテストケースの違いは何ですか？ テスト仕様書は、テストの範囲・環境・観点と、テストケースの一覧をまとめた文書全体を指します。テストケースは、その中の1件ごとの確認内容で、前提条件・手順・入力値・期待結果の組です。「テスト仕様書を何冊」「テストケースを何件」と数え方も異なるため、見積もりや進捗報告ではどちらの単位で話しているかをそろえておくと誤解が起きません。 ### テスト仕様書はExcelで作っても問題ありませんか？ 数百件規模までならExcelやスプレッドシートで十分に運用できます。要件ID・ケースID・実施結果の列を設け、版数を表紙で管理すれば、検収の根拠資料としても通用します。複数の担当者が同時に実施する、改修のたびに同じケースを繰り返す、不具合票と自動で紐付けたいといった条件がそろったら、テスト管理ツールへの移行を検討する時期です。 ### テストケースは何件あれば十分ですか？ 件数に正解はなく、件数で品質を判断するのは避けてください。見るべきは、すべての要件に1件以上のケースが対応しているか、境界値と異常系が含まれているかの2点です。同値分割法と境界値分析で導いたケースは、似たケースの水増しを防げるため、同じ範囲を確かめるのに必要な件数を減らせます。件数よりも要件のカバー状況を報告してもらう方が判断に使えます。 ### アジャイル開発でもテスト仕様書は必要ですか？ 分厚い仕様書を最初に作る形はとりませんが、確認内容を書き残す必要は変わりません。JSTQBシラバスでは、ユーザーストーリーの受け入れ基準をテスト条件として扱う考え方が示されています。スプリントごとに受け入れ基準とテストケースを更新し、繰り返し使うケースは自動テストに置き換えていく運用が一般的です。請負で発注する場合は、検収の基準をどの文書で持つかを契約時に決めておきます。 ## 関連記事 - [外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点](https://www.issoh.co.jp/column/details/13134/)：テスト仕様書の元になる外部設計書を、発注者がどう承認するかを解説しています。 - [探索的テストとは？チャーター設計・セッション記録と自動テスト化](https://www.issoh.co.jp/tech/details/16258/)：仕様書に書き切れない不具合を見つける、テストケースに頼らない手法です。 - [システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定](https://www.issoh.co.jp/tech/details/15319/)：テスト仕様書を含む品質管理全体の進め方と判定指標をまとめています。 --- 出典: [テスト仕様書とは？書き方とテストケースの項目・発注者がレビューで見る観点]()（株式会社一創）