キャリア

テスト仕様書を作成するために必要な情報まとめ

秋本直樹

インフラエンジニア/ボールド歴2年

最終更新日:2026/1/23

テスト仕様書の作成方法について、気になった事はないでしょうか。
ただ、具体的な目的や、仕様書に記載すべき情報についてはよく知らない人もいると思います。
本記事では、テスト仕様書の目的や必要情報、記載例について解説します。

１．テスト仕様書とは何か
２．テスト仕様書の作成ステップ
3．さいごに

１．テスト仕様書とは何か

ソフトウェアテストの枠組みとなるテスト仕様書。
その目的から仕様書作成に必要な情報について、「1.1～1.3」で説明していきます。

１-１．テスト仕様書の目的

テスト仕様書とは、「ソフトウェアが要件通りに機能するかを確認するため、テストの要点をまとめた」文書になります。
主に以下のような目的をもって作成するので、仕様書作成後は以下を満たせる仕様書になっているか確認すると良いでしょう。

品質向上
テストの効率化、網羅性確保
コミュニケーションの円

１-２．テスト仕様書作成に必要な情報

　仕様書作成に必要な情報は、主に「対象範囲」「確認内容」「実施条件」「手順」「期待結果」の5つです。これらの情報について、以下に注意しながら明確化します。

　対象範囲：対象の機能、モジュールは何か、バージョン、対象環境など
　確認内容：テストで確認したい内容（例：「○○機能の正常動作を確認する」など）
　実施条件：テスト実行する環境(ハードウェア、OSなど)、前提条件(特定データを利用するなど)
　手順　　：(誰でも操作できるような)詳細な操作手順、エビデンスの取得方法や退避先など
　期待結果：テストを実施して期待する結果を記載(正常系と異常系の両方を記載する)

１-３．テスト仕様書作成のポイント

仕様書作成時、まずは「要件定義の確認」をしてテスト内容を整理します。
そして、網羅性のあるテストになるよう心がけましょう。（正常系だけになっていないか、抜けている観点が無いかなど）
また、テスト内容を記載する際は、内容を明確にして曖昧な表現を避けること、フォーマットや記載ルールを統一して、誰でも同様にテストを実施できるような内容にしましょう。
なお、仕様書は一度作成しても急な仕様変更が発生する場合があります。変更点の漏れやテスト内容の矛盾等が発生しないよう注意しましょう。

２．テスト仕様書の作成ステップ

テスト仕様書の詳細な作成方法について、計画立案からレビューまでを「2.1～2.4」で紹介します。

２-１．テスト計画の立案

要件定義に従い、テスト計画を作成します。
どのフェーズ（単体・結合・システムテストなど）で仕様書を作成するのかを決め、仕様書の構成（テスト目的・範囲、スケジュール、必要リソースなど）を決定します。
構成が決まったら以下の様に仕様書の枠を作成していきます。

１．テストケース対象の枠を作成します。
　　以下サンプルを参考に、「対象システム名」や「対象モジュール名」等の入力枠を作成します。
　　また、作成日や作成者などの履歴欄も用意します

２．次にテスト項目の枠を作成します。
　　以下サンプルを参考に、「項目名」や「前提条件」、「テストの手順」や「そのテストで期待する結果」の入力枠を作成します。
　　なお、以下サンプルでは大～小二項目を分けていますが、対象システムの項目数によって大～中に変更するなどしてください。

３．最後にテスト結果の枠を作成します。
　　今までの枠(テスト前に記入する枠)と違い、「テスト実施者」が入力する枠なので、実施者が「テスト結果について記載漏れが発生しない」ように枠を作成します。
　　例えば以下サンプルの様に、「結果の成否」と「結果の詳細」を分けるなどして、記入者も確認者も分かりやすいような入力枠を作成します。

２-２．必要項目の整理

記載項目を整理し、ドキュメントに落とし込んでいきます。
1.2でも記載した、「対象範囲」「確認内容」「実施条件」「手順」「期待結果」の5つを、1.3に記載したポイント（網羅性、詳細なテスト手順、異常系テストも記載するなど）を押さえながら整理していきます。
今回は以下のようなシステム群の内、赤字部分のテスト仕様書を作成すると仮定して、2.1で作成した大枠の中に必要事項を記載していきます。

① テストの対象について記載していきます。
　今回は上記赤字のシステム、モジュール、機能が対象なので、以下の様に記載していきます。
　なお、仕様書は各機能で作成するため、上記の全システムをテストする場合「サンプル機能1～6」の計6通りのテスト仕様書が必要です。
　（もしシステムAだけならば1～4の4通りになります。テスト範囲は2.1の段階で精査しましょう）

② 次にテスト項目を記載していきます。
　以下サンプルでは、サンプル機能1に「ホームメニュー」「データメニュー」の大きく2つメニューがあると仮定し、メニューに存在するボタン(機能)を書き出しています。
　(No1であれば、”ホームメニューの中に「フォント」ボタンがあり、ボタンを押下すると更に太字～下線のボタンがある”と仮定)
　また、テストする上で必要な「前提条件」と「テスト手順」、「期待する結果」についても詳細に記載し、「誰がテストしても同様な結果」を得られるようにします。（備考欄はあくまで補足程度）

２-３．レビューと修正

テスト仕様書を作成したらレビューを実施します。
まずは「システム開発者」や「システム設計者」といった複数の視点でレビュー頂くと、不足しているテスト項目や足りない手順に気付けるなど、より品質が高くなります。
その後はテスト担当者にレビュー頂き、作成したテスト仕様書でテストを完遂できるか判断頂きます。また、一度レビューが完了しても仕様変更があった場合などはすぐに修正を反映し、再度レビュー頂きましょう。
(ただし、あまりに頻繁な仕様変更があるとテスト実施が遅れるため、テスト期間を考慮して仕様の確定時期などを担当者に相談しておきましょう)

２-４．テストの実施

テスト仕様書のレビューが完了したら、実際にテストを実施します。
(仕様書作成者と実施者は同一人物とは限りません)テスト実施後、全ての結果が期待通りであれば問題ありませんが、期待通りにならなかった点があれば、すぐに原因調査と機能修正(又は回避手順の作成)に入ります。
以下サンプルの場合は、No5のテストでNGとなっていますが、この際に結果詳細欄に記載された内容に不明点があればテスト実施者にヒアリングする他、エビデンスを取得していればエビデンス確認をします。