テスト仕様書とは？書き方・項目とテンプレートの使い方

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。

テスト仕様書とは？何のために書くのか

国際的な用語の規格 ISO/IEC/IEEE 24765:2010 では、specification の例として、要求仕様や設計仕様と並んで test specification が挙がっています。テストのやり方も、仕様として決めて書いておくもの、というわけです。

テスト仕様書が無いと、テストする人の頭の中にしか確かめ方が残りません。後から『このテスト、何を確かめたんだっけ？』となった時に、誰も答えられなくなってしまうんです。

テスト仕様書を書く3つの理由

特に3つ目は大事です。テストの前に、発注側や設計した人と「どうなれば合格か」を合わせておけば、終わった後のもめごとが減ります。

テストの段階ごとに仕様書がある

テスト仕様書は、テストの段階ごとに作るのが一般的です。デジタル庁のデジタル・ガバメント推進標準ガイドライン（DS-100）でも、開発する事業者に「単体テスト、結合テスト及び総合テスト」のテスト計画書の案を求めています。

テスト計画書・手順書・報告書との違い

『テスト仕様書とテスト手順書って何が違うの？』と迷う方は多いですよね。テストまわりの書類を並べてみます。

DS-100では、テスト計画書にテスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ作成基準、合否判定基準などを書くこととされています。テスト仕様書は、この計画に沿って中身を書く書類と考えると分かりやすいです。

テスト仕様書の1行は「前提・手順・期待結果・判定」の4列で書く

テスト仕様書の書き方で迷った時は、1行を4つの列に分けて考えてみてください。編集部では、次の記入表を基本の形にしています。

テスト仕様書の記入例

編集部が作った架空の例で、会員の「パスワードを変える」機能のテストを書いてみますね。

こうして書くと、テストをする人は表を上から順になぞるだけで済みます。初めてその機能を触る人でも、同じ確かめ方ができるんです。

期待結果の書き方で差がつく

4列のうち、一番あいまいになりやすいのが期待結果です。例えば、こんな書き方をしていませんか。

「正常に変更されること」

これでは、何を見れば「正常」なのかが人によって変わります。画面に何が出るか、データがどう変わるかまで書くと、判定に迷わなくなります。

前提の書き忘れにも気をつける

期待結果と同じくらい抜けやすいのが、前提の列です。書いた本人には当たり前の状態でも、ほかの人には分かりません。

例えば、テストの途中でこんなやり取りが起きがちです。

「この項目、どの会員でログインして試せばいいですか？」
「あ、ポイントを持っている会員じゃないと、この画面は出ないんです」

こうした情報は、前提の列に書いておけば聞き返されずに済みます。権限、データの状態、日付や時間の条件などは、特に書き忘れやすいので見直してみてください。

テスト仕様書の書き方：項目の作り方と技法

いきなり1行目から書き始めるより、先に「何を確かめるか」を拾い出しておくと、抜けが減ります。

JSTQBのシラバス（Version 2023V4.0.J02）では、テストの元になる情報を分析して確かめられる条件を見つけることをテスト分析、その条件をテストケースに落とし込むことをテスト設計と呼んでいます。上の手順の2がテスト分析、3がテスト設計に当たります。

書き始める前にそろえておくもの

テスト仕様書を書く前に、元になる書類の版を確かめておきましょう。古い版の設計書から項目を作ると、テストの日に『画面が違う』と気づくことになりかねません。

あわせて、テスト環境やテスト用のデータをどう用意するかも、計画書や先輩に確かめておくと安心です。前提の列が書きやすくなります。

機能ごとの確かめどころは、機能仕様書に書いた「入力・処理・出力・例外」がそのまま手がかりになります。機能仕様書の書き方は機能仕様書とは？書く項目と書き方で紹介しています。

ブラックボックステストの考え方

仕様から項目を作る方法は、プログラムの中身を見ない「ブラックボックステスト」と呼ばれます。入力と出力だけに注目して、決めたとおりの結果になるかを確かめます。

よく使われるのは、同じ結果になる値のグループから代表を選ぶ考え方と、条件が切り替わる値の前後を確かめる考え方です。例えば「一定の数以上で割引」なら、ちょうどその数と、1つ手前の数を両方試します。

ホワイトボックステストの仕様書の書き方

ホワイトボックステストは、プログラムの中身を見て、分かれ道や処理の道を通るように項目を作る方法です。主に単体テストで使われます。

ホワイトボックステストの仕様書を書く時は、前提と手順に加えて「どの分かれ道を通すための項目か」を書く列を足しておきましょう。後から見た時に、通していない道があればすぐ分かります。

シナリオテストの仕様書の書き方

シナリオテストは、使う人の一連の操作をひとつの物語のように並べて確かめる方法です。例えば「会員登録してから、商品を選び、注文して、注文の履歴を見る」までを1本で確かめます。

シナリオテストの仕様書では、前の行の結果が次の行の前提になるように並べます。どこで流れが止まったかが分かるように、行ごとに期待結果を書いておきましょう。

テスト仕様書のテンプレートの作り方と使い方

テスト仕様書のテンプレートは、会社やチームで決まっていることも多いです。新しく作る時は、次の形を土台にしてみてください。

テスト項目のシートには、不具合が見つかった時に管理番号を書く「備考」の列があると便利です。直した後にもう一度テストした結果も、同じ行に書けるようにしておきましょう。

Excelでテンプレートを作る時のひと工夫

テスト仕様書のテンプレートをExcelで作るなら、判定の列は選択式にしておくと、表記がばらつきません。「合格」「不合格」「保留」の3つから選ぶ形にしておけば、集計のシートも作りやすくなります。

手順の列は、セルの中で改行して1行に1つの操作を書くと読みやすくなります。1つのセルに長い文章を詰め込むより、操作の数だけ行を分けるほうが見やすい場合もあるので、チームで書き方をそろえておきましょう。

テンプレートを使う時に気をつけたいこと

『テンプレートの欄を全部埋めないといけない？』と思う方もいますよね。結論から言うと、使わない欄は消してしまってかまいません。

設計が変わった時は、テスト仕様書も一緒に直します。どの設計の変更に合わせて直したかを変更履歴に残すと、レビューの時に追いやすくなります。見直しの観点は設計書・仕様書のレビュー観点も参考にしてみてください。

テスト仕様書でよくある相談

知恵袋で多く読まれている相談を、内容を要約して答えてみますね。

相談1：単体・結合・システムテストの仕様書の書き方が分からない

『テストの段階ごとに、どう書けばいいか分からない。くわしく載っている所を知りたい』という相談です。とても多くの人に読まれています。

結論から言うと、どの段階でも4列（前提・手順・期待結果・判定）で書く点は同じです。違うのは、確かめる範囲と元にする書類です。

まずは単体テストで4列の書き方に慣れてから、結合テスト、総合テストへと広げていくと、無理なく身につきますよ。

相談2：テスト仕様書とテスト手順書の違いは？

『勉強の演習で、テスト仕様書とテスト手順書の両方が出てきて違いが分からない』という相談です。

テスト仕様書は「何を確かめ、どうなれば合格か」を、テスト手順書は「どの順にどう操作するか」を書く、と分けるのが一般的です。小さな開発では、仕様書の手順の列に操作を書き込んで、1つにまとめることもよくあります。

相談3：生成AIに、仕様を教えずにテスト仕様書を作ってもらえる？

『仕様は教えられないけれど、生成AIにテスト仕様書を作ってもらえる？』という相談です。

結論から言うと、仕様を渡さずに作らせたテスト仕様書は、一般的な項目の例にとどまります。期待結果は仕様から決まるので、仕様が無いと「どうなれば合格か」を書けないんです。

社外に出せない情報を扱う時は、会社の決まりを確かめたうえで、生成AIには項目の型づくりだけを手伝ってもらうのが安心です。下書きのさせ方と確かめる所は仕様書をAIで作る｜生成AIに下書きさせる手順で紹介しています。

相談4：テスト仕様書は、プログラムを作る前と後のどちらで作る？

『テストケースは、プログラムを作る前に用意するもの？ 作った後でいいの？』という相談です。

結論から言うと、設計が固まった時点で作り始め、プログラムを作る前か並行して用意しておくのがおすすめです。先に期待結果が決まっていれば、作る人も「どうなれば合格か」を意識しながら作れます。

作った後にテスト仕様書を書くと、できあがった動きをそのまま期待結果に書いてしまいがちです。それでは、設計とのずれに気づけなくなってしまうんです。

テストの書類を書く経験は、次の一歩にもなる

テスト仕様書を書くと、設計書や要件定義書を「確かめる側」から読む力がつきます。この力は、要件定義や設計などの上流工程でも役に立ちます。

今の職場で設計の担当に少しずつ近づくのも、資格を取ってから動くのも、どちらもよい道です。今の担当工程から一歩進みたい方は、求人の仕事内容を比べてみると、どんな経験が評価されるかが見えてきます。

上流工程に進む道筋は上流工程とは？要件定義・設計ができるエンジニアになる道筋で紹介しています。

よくある質問

まとめ

あわせて読みたい

単体テスト仕様書の書き方｜テスト項目の作り方とテンプレート

結合テスト仕様書の書き方｜総合テスト・受入テストとシナリオの作り方

仕様書とは？意味と目的、設計書・要件定義書との違い