テスト仕様書の書き方｜基本構成とテンプレート、テスト設計との違い

「今度の案件、テスト仕様書の作成からお願いできる？」

現場でリーダーからそう言われたとき、心臓が跳ね上がるような不安を感じたことはありませんか。 正直に申し上げますと、デバッグバイト時代の私は、この言葉が一番苦手でした。

「エクセルのフォーマットはあるんですか？」
「テスト項目って何を書けばいいんですか？」

そう聞き返すと、「適当に前のやつ参考に作っておいて」と返されるだけ。
正解がわからないまま、見よう見まねで作った資料はレビューで真っ赤に修正され、自分の無力さを突きつけられる日々でした。
当時の年収は230万円。毎日終電までバグを探しても、時給は一向に上がらず、「自分はずっとこのままなのだろうか」と絶望していたことを昨日のことのように思い出します。

しかし、今は断言できます。 「テスト仕様書」には、明確な「型」があります。

才能やセンスは必要ありません。
標準的な構成とルールさえ知ってしまえば、誰でも抜け漏れのない仕様書は書けるのです。そして何より、この「設計スキル」こそが、言われたことだけをやるテスターから、市場価値の高いQAエンジニアへとステップアップするための鍵となります。

この記事では、私が未経験からQAエンジニアに転職し、現場で揉まれる中で学んだ「実務で使えるテスト仕様書の書き方」を、包み隠さずお伝えします。専門用語だらけの解説書ではなく、明日からの仕事にそのまま使える「現場の虎の巻」として活用してください。

テスト仕様書とは？基本構成と役割

まず最初に、「テスト仕様書」という言葉の定義について整理しておきましょう。 実は、この言葉が指す範囲は、現場や企業によって驚くほどバラバラです。

• A社：「テストの方針をまとめた資料（計画書寄り）」
• B社：「具体的なテスト手順を書いたチェックリスト（テストケース寄り）」
• C社：「その中間の、テスト設計を記したドキュメント」

この認識のズレが、初心者を混乱させる最大の原因です。 しかし、QAエンジニアとして標準的な定義（IEEE829などの国際規格をベースにした考え方）を知っておけば、どの現場に行っても「ああ、この現場ではこれを仕様書と呼んでいるんですね」と冷静に対応できるようになります。

テスト計画書・テスト設計書・テストケースとの違い

テストドキュメントは、大きく分けて3つの階層構造になっています。 まずは以下の図で、それぞれの役割と関係性をイメージしてください。

それぞれの違いを、家づくりに例えて解説します。

ドキュメント名	家づくりでの例え	QA現場での役割
テスト計画書	建築計画・スケジュール	「何を、いつまでに、誰が、どういう方針でテストするか」を定義する最上位の文書。
テスト仕様書（設計書）	設計図・図面	「どの機能を、どのような条件や観点で確認するか」というテストの構造（ロジック）を定義するもの。
テストケース（手順書）	施工マニュアル・チェック表	仕様書に基づき、「具体的な操作手順、入力値、期待値」を1行単位で落とし込んだチェックリスト。

私たちが普段、現場で「チェックリスト」や「項目書」と呼んでポチポチとOK/NGをつけているエクセル。あれは、厳密には 「テストケース（テスト手順書）」 にあたります。

一方、今回解説する 「テスト仕様書」 は、そのチェックリストを作るための 「設計図」 です。 「ログイン機能をテストする」という要件に対し、「正常なIDとPWの場合」「IDのみ未入力の場合」「アカウントがロックされている場合」……といった 「テスト観点（切り口）」 を洗い出し、テストケースへと落とし込むための中間成果物。これがテスト仕様書です。

多くの現場では、この「仕様書（設計）」と「ケース（手順）」が1つのエクセルファイルにまとまっていることが多いため、混同されがちです。

なお、具体的な「テストケース（チェックリスト）」の細かい作り方や、効率的な項目の洗い出し方については、以下の記事で詳しく解説しています。まずは「仕様書」で全体像を理解してから、詳細な手順作成に進むのがスムーズです。

テストケース（チェックリスト）の作り方｜現場で使えるテンプレートと抜け漏れを防ぐコツ

なぜ仕様書が必要なのか（属人化の防止と品質担保）

「いちいち仕様書なんて書かずに、直接チェックリストを作れば早くないですか？」 デバッグバイト時代の私は、本気でそう思っていました。納期も短いし、動かせばバグなんて見つかるだろう、と。

しかし、仕様書（設計）を飛ばしていきなり項目を作り始めると、必ず以下のトラブルが起きます。

1. 抜け漏れが発生する
   • 思いつきで項目を追加していくため、「文字数制限の上限チェック」や「通信切断時の挙動」といった、システム的に重要な観点が漏れます。
2. メンテナンスができない
   • 仕様変更があったとき、設計図がないため「どこの項目を直せばいいか」が分からず、数千行のリストを目視で探すことになります。
3. 品質説明ができない
   • クライアントや開発者に「どこまでテストしたの？」と聞かれたとき、「思いつく限りやりました」としか答えられなくなります。これではプロの仕事とは言えません。

「品質を保証（Assurance）する」 のがQAエンジニアの仕事です。 「なんとなくバグを見つけました」ではなく、「この設計図に基づいて網羅的に確認し、問題ないことを証明しました」と言えるようになること。これが、テスト実施者からQAエンジニアへレベルアップするための第一歩です。

QAエンジニアという職種の全体像や、設計スキルがどう評価に繋がるかについては、以下の記事も参考にしてください。

QAエンジニアとは？仕事内容や年収、未経験からのなり方を徹底解説

国際規格（IEEE829）を日本の現場向けに噛み砕くとどうなるか

少しだけ専門的な話をしますが、怖がらないでくださいね。 ソフトウェアテストには「IEEE829」という、テストドキュメントの国際標準規格があります。この規格では、テスト仕様書をさらに細かく定義していますが、日本の実際の開発現場（特にWebやゲーム業界）で、この規格通りにガチガチのドキュメントを作っている所は稀です。

そんなことをしていたら、開発スピードについていけません。

現場で求められるのは、 「IEEE829の考え方をベースにしつつ、実務に合わせて軽量化したフォーマット」 です。 次章からは、私が実際に多くの現場で使用し、「使いやすい」「わかりやすい」と評価された、実用的なエクセルの構成テンプレートを紹介します。

【エクセル/スプレッドシート】テスト仕様書の構成要素とテンプレート

それでは、具体的なテスト仕様書の書き方に入りましょう。 多くの現場では、ExcelやGoogleスプレッドシートを使用します。テスト管理ツール（TestRailなど）を導入している企業もありますが、基本となる構成要素は同じです。

テスト仕様書に必要な要素は、大きく分けて4つあります。

1. ヘッダー情報（管理情報）
2. テスト環境と前提条件
3. テスト項目（操作と期待値）
4. 合否判定基準

これらが1シート（または別シート）にまとまっていることで、誰がいつ見てもテストの内容を理解できるようになります。一つずつ詳細を見ていきましょう。

①ヘッダー情報（ID、対象機能、作成者、バージョン）

ドキュメントの「表紙」にあたる部分です。 「そんなの飾りでしょう？」と思うかもしれませんが、ここが一番重要だと言っても過言ではありません。

なぜなら、開発現場では 「仕様変更」 が日常茶飯事だからです。
「いつの時点の」「どの仕様書を元にした」テストなのかが明確でないと、後でバグが出たときに「テスト漏れ」なのか「仕様変更によるデグレ（劣化）」なのか判断できません。

• プロジェクト名: どの案件のテストか（例: ECサイトリニューアル）。
• テスト仕様書ID: 仕様書を一意に識別する番号（例: SPEC-EC-001）。
• 作成者 / 作成日: 誰がいつ作ったか（例: 山田太郎 / 2026/1/24）。
• テスト環境（OS/ブラウザ）: どの環境で実施するか（例: Windows 11 / Chrome 118）。
• 参照機能仕様書: 元ネタにした要件定義書や設計書のファイル名とバージョン（例: FNSPEC-EC-001 (Ver 1.0)）。

特に一番右の 「参照機能仕様書（参照ドキュメント）」 の記載は必須です。
例として「FNSPEC-EC-001 (Ver 1.0)」を元に作成と明記してあれば、
もし「FNSPEC-EC-001 (Ver 1.1)」に更新された際、
このテスト仕様書も修正が必要だとすぐに分かります。ここが抜けていると、仕様変更の波に飲まれて現場が混乱します。必ず残すようにしましょう。

②テスト環境と前提条件（OS、ブラウザ、テストデータ）

「バグが出たので報告したら、『いや、そのOS対象外だから』と言われた」 ……こんな経験、ありませんか？ 私はあります。あれは本当に悔しいですよね。

こうした無駄な工数を防ぐために、「どのような環境・条件でテストを行うか」を事前に明記します。

• 検証端末 / OS: iPhone 14 (iOS 16.0), Pixel 7 (Android 13) など。
• ブラウザ: Chrome, Safari, Edgeなど。バージョンも指定するとベスト。
• テストデータ:
  • 「通常会員アカウント」を使用するのか、「管理者アカウント」なのか。
  • 「課金済みデータ」が必要なのか、「新規ユーザー」なのか。
• 通信環境: Wi-Fi環境か、4G/5G環境か（通信エラー系のテストで重要）。

ここが曖昧だと、テスターは「手元にある端末で適当に」確認してしまいます。 後になって「実はAndroidだけで発生するバグだった」と判明した場合、テストをやり直すコストは甚大です。 「前提条件の定義」こそが、QAエンジニアの腕の見せ所 です。

③テスト観点と範囲（何を検証するか・Scopeの定義）

テスト仕様書のメインパートですが、ここで注意点があります。
ここでは 具体的な「操作手順（1. ボタンを押す、2. 確認する、・・・等）」は書きません。

それは、この後の工程で作る「テストケース（手順書）」の役割です。
テスト仕様書で書くべきなのは、「どの機能を、どのような切り口（Viewpoint）で確認するか」 という設計情報です。

• 大項目 / 中項目 / 小項目: 機能の分解（例: 会員登録機能 > エラーチェック）。
• 確認観点（Viewpoint）: 何を検証したいのか（例: 必須項目が未入力の場合、登録できないこと）。
• 優先度: そのテストの重要度は高いか低いか。

このように、
テスト仕様書では 「何を狙うか（What）」 を定義し、
テストケース（テスト項目書）で 「どうやるか（How）」 を記述します。
ここを混同して仕様書に細かい手順を書き始めてしまうと、メンテナンス性が極端に下がり、設計の全体像が見えなくなってしまいます。

具体的な操作手順（1操作・1確認）に落とし込むフェーズについては、以下の記事で解説している「テストケース作成」のステップに進んでください。

テストケース（チェックリスト）の作り方｜現場で使えるテンプレートと抜け漏れを防ぐコツ

④合否判定基準（Pass/Failの定義）

最後に、テスト全体としての「合格（Pass）」と「不合格（Fail）」のラインを定義します。

「NGが1個でもあったらリリース不可ですか？」と聞かれることがありますが、現実はそう単純ではありません。 例えば、「文字の表示が1ドットずれている」という軽微なバグがあったとして、そのためにサービス全体のリリースを延期するかというと、多くの場合は「既知の不具合」としてリリース（Goサイン）を出します。

• リリースOK基準: 重要度「高」のバグが0件であること。
• 条件付きOK基準: 重要度「中・低」のバグが残っているが、回避策があり、PMの承認が得られていること。
• NG基準: サービスの根幹に関わる機能（ログイン、決済など）にバグが残っていること。

このように、 「どのような状態になればテスト完了と言えるのか」 を事前に握っておくことが、プロジェクト終盤の炎上を防ぐ防波堤となります。

ここまで、テスト仕様書の標準的な構成要素について解説してきました。 「なんだか難しそう……」と感じた方もいるかもしれません。

ですが、安心してください。 最初から完璧な仕様書を書ける人はいません。大切なのは、今ある現場の資料を見て 「あ、ここは前提条件が抜けているな」「ヘッダーに参照元がないから追記しよう」 と気づけるようになることです。

この「気づく視点」を持っているだけで、あなたの市場価値は大きく変わります。 言われた通りのテストをするだけの「テスター」と、品質をコントロールできる「QAエンジニア」。その分かれ道は、こうしたドキュメント作成の基礎知識にあるのです。

もしあなたが、今の現場で「ただ言われた手順をこなすだけ」の毎日に危機感を持っているなら。あるいは、もっと上流の「設計」に関わって年収を上げたいと考えているなら。 それは、あなたが次のステージに進む準備ができている証拠です。

ご自身の経験年数や状況に合わせて、一度「自分の市場価値」を確認してみてはいかがでしょうか。以下に、私が自信を持っておすすめできる環境を紹介しておきます。

レビューで「一発OK」をもらうための3つの定義

ここからは、より実践的なテクニックのお話です。

私がQAエンジニアとしてデビューしたての頃、自信満々で出した仕様書が、開発リーダーから突き返されたことがありました。 「転すけさん、これだと『何を確認したいのか』が見えてこないよ」 「えっ、機能は全部網羅したつもりですが……」 「網羅はしてるけど、強弱がない。全部均等にテストする時間なんてないんだよ」

当時の私は、ただ闇雲に項目を並べることだけが「仕様書作成」だと思っていました。しかし、プロの現場で求められるのは、限られたリソースの中で品質を最大化するための 「戦略」 です。

現場のレビューで「いいね、わかってるね」と言われる仕様書には、必ず以下の3つの定義が含まれています。

①テスト範囲（Scope）と除外範囲の明記（「なんとなく全部」はNG）

一番やってはいけないのが、テストの範囲をあやふやにしたまま進めることです。

例えば「チャット機能のテスト」と言われたとき、あなたはどこまで確認しますか？
テキスト送信、スタンプ、画像添付、既読表示……。
機能は多岐にわたりますが、さらに「通信環境が悪い場合」や「旧機種での動作」まで含めると、テスト項目は無限に増えてしまいます。

だからこそ、仕様書の冒頭で 「ここはやります（Scope）」 と 「ここはやりません（Out of Scope）」 を宣言する必要があります。

• 対象範囲: チャットの送受信（テキスト、画像）、通知機能。
• 除外範囲: ビデオ通話機能（今回は改修対象外のため）、Android 8.0未満の端末。

これを明記せずにバグが出ると、「なんで確認してないんだ！」と怒られます。しかし、事前に「今回は対象外とします」と定義し、合意を得ていれば、それは「想定内のリスク」として管理できるのです。

②テスト観点の構造化（手順を書く前に「何のバグを狙うか」を設計する）

次に重要なのが、テスト項目の「構造化」です。 いきなり「ボタンを押す」という手順を書き始めてはいけません。まずは「どのような切り口でバグを探すか」という 「観点（テストアイデア）」 を整理します。

• 機能の観点: 正常に動くか、必須入力チェックは効くか。
• データの観点: 最大文字数、特殊文字、空データ。
• 状態の観点: ログイン直後、タイムアウト直前、課金ユーザー。

これらをツリー状に整理し、「今回はこの観点を重点的に攻めます」という設計図を見せること。これこそが「仕様書」の役割です。 具体的な手順（テストケース）は、あくまでこの設計図を具現化したものに過ぎません。

③前提条件とテストデータの独立性（誰がいつ実施しても環境が再現できるか）

3つ目は、テストの 「再現性」 です。
「私のPCではテストできたんですけど……」という言い訳は、プロの現場では通用しません。

誰が、いつ、どの環境で実施しても同じ結果になるように、前提条件を独立させる必要があります。

このように、テストに必要な「初期状態」まで定義することで、テスト実施者の迷いをなくし、手戻りを防ぐことができます。

テスト仕様書作成の具体的な手順（5ステップ）

ここからは、実際にゼロからテスト仕様書を作成する際の流れを、5つのステップで解説します。 いきなり詳細な手順（テストケース）を書き始めるのは、地図を持たずに森に入るようなものです。

「やり直しや齟齬」を防ぎ、効率よく品質を担保するための「正攻法」をご紹介します。

1. 要件定義書・基本設計書の読み込み（インプット確認）

まずは「仕様を正しく理解する」ことからです。
開発チームから共有された資料（要件定義書、基本設計書、UI/UXデザイン案など）を読み込みます。

ここで重要なのは、「何が正解か」を理解すること です。 仕様書に「不明」や「？」がある状態でテスト設計に入ると、必ず後で修正が発生します。

• 「このボタンを押した時のエラーメッセージは何ですか？」
• 「文字数制限の上限は何文字ですか？」

不明点があれば、この段階で遠慮なく開発者やPM（プロジェクトマネージャー）に質問しましょう。QAエンジニアからの鋭い質問は、開発者がまだ気づいていない仕様の矛盾を早期発見することにも繋がります。

2. テスト環境・前提条件の定義（ヘッダー情報の確定）

資料を読み込んだら、まずは「外枠」から固めます。 先ほどのテンプレート解説でも触れた「ヘッダー情報」と「テスト環境」です。

• 検証に使用するOSとブラウザのバージョン
• テストに使用するサーバー環境（開発環境？ ステージング環境？）
• テストデータの準備方法

これらが決まっていないと、詳細なテスト手順を書きようがいありません。まずはプロジェクトの前提条件を明確にし、関係者と合意を形成します。

3. テスト観点の洗い出し（機能・非機能の網羅）

次に行うのが「観点出し」です。マインドマップツール（Xmindなど）を使うと整理しやすいでしょう。

ここでは、細かい手順ではなく 「確認すべき要素」 を洗い出します。

• 機能要件（Functional）:
  • 画面遷移は正しいか。
  • データの保存・削除はできるか。
• 非機能要件（Non-Functional）:
  • 画面のロード時間は許容範囲内か。
  • セキュリティ（権限のないページへのアクセス）は防げているか。

この段階では「網羅性」を重視します。「あ、そういえばこんなケースもあるかも」というアイデアを出し切ることが大切です。

4. テストシナリオ・バリエーションの設計（手順記述の前段階まで）

観点が出揃ったら、それを「どのような組み合わせで確認するか」を設計します。ここがQAエンジニアの腕の見せ所です。

例えば「会員登録」のテストなら、以下のようなバリエーションが考えられます。

• パターンA：全項目に入力して登録（正常系）
• パターンB：必須項目のみ入力して登録（正常系・最小構成）
• パターンC：必須項目を空にして登録（準正常系・エラー確認）

これを「手順」として書く前に、表形式（デシジョンテーブル）などで整理します。 「1行ずつ手順を書く」のは、この設計が固まった後の「作業」です。仕様書作成のフェーズでは、この 「組み合わせのロジック」 を構築することに集中してください。

5. 仕様書（設計）としてのレビュー（ケース作成前の合意形成）

最後に、作成した設計（観点とシナリオの構成案）をチーム内でレビューします。

詳細な手順（テストケース）を書く前にレビューを受けること。 これが最大の時短テクニックであり、絶対に守ってほしい鉄則です。

数千行の手順書を書き終わってから「いや、この機能は今回テスト対象外だよ」とか「この観点が抜けてるよ」と言われたら、数日分の作業が無駄になります。 「骨子」の段階で合意を取ることで、手戻りを最小限に抑え、自信を持って詳細手順の作成（次のフェーズ）に進むことができます。

なお、テスト実行中にバグを見つけた際の「報告ルール」もこの段階で確認しておくとスムーズです。開発者に喜ばれるバグ報告書の書き方については、以下の記事も参考にしてください。

バグ報告書の書き方｜開発者が「修正したい」と思えるレポート作成術

まとめ：仕様書は「品質の設計図」。型を覚えれば応用できる

今回は、初心者の方に向けて「テスト仕様書の書き方」を解説してきました。 長くなってしまいましたが、重要なポイントを振り返ってみましょう。

1. 仕様書とケースの違い: 仕様書は「設計図」、ケースは「手順書」。
2. テンプレートの活用: 共通の型を使うことで、誰でも一定の品質を出せる。
3. レビューの極意: 「範囲」「観点」「独立性」を定義し、手順を書く前に合意を取る。

テスト仕様書は、単なるドキュメントではありません。 プロダクトの品質を保証するための 「設計図」 です。

私が年収230万円のデバッグバイトから抜け出せたのは、ただ言われた通りにバグを探すだけでなく、この「設計図」を書けるようになったからでした。
「どうすれば効率よく網羅できるか？」「どこにバグが潜んでいそうか？」を論理的に考え、文書化するスキル。
これさえあれば、あなたはもう「テスター」ではなく立派な「QAエンジニア」です。

設計スキルが身についたら、QAエンジニアとして単価アップを目指しましょう。
あなたの市場価値は、あなたが思っている以上に高まっているはずです。

もし今の現場で「仕様書作成」のチャンスがない、あるいは正当に評価されていないと感じるなら、外の世界を見てみるのも一つの手です。 設計経験があれば、待遇は劇的に変わります。私が自信を持っておすすめできるエージェントを下にまとめておきました。

あなたの次のステップが、実りあるものになることを心から応援しています。