テスト仕様書の書き方｜テストケースの記入例と観点の洗い出し方

テスト仕様書とは、「何を、どんな条件で、どう操作したら、どうなれば正しいか」を一覧にした文書です。1行が1つのテストケースで、誰が実施しても同じ手順で確認でき、同じ基準で合否を判断できるように書くことが目的です。

書き方の型はシンプルですが、難しいのは「どんなテストケースを用意すれば十分か」を決めることです。この記事では、必要な項目と書き方を整理したうえで、会員登録画面を例にした記入例と、同値分割・境界値分析・デシジョンテーブルといったテストケースを漏れなく洗い出す技法を解説します。最後に、レビューで使えるチェックリストも紹介します。

テスト仕様書の早見表

テスト仕様書の項目

要件IDの列を設けておくと、「すべての要件に対応するテストがあるか」を確認できます（トレーサビリティ）。要件定義書で要件IDを付けておくと、ここで活きてきます。

期待結果の書き方

テスト仕様書で最も大切なのが期待結果です。期待結果があいまいだと、実施する人によって合否の判断が変わってしまいます。

期待結果には、画面の表示だけでなく、データの状態（登録されたか、されていないか）も書くと、確認漏れを防げます。エラーの場合は、「エラーが表示される」だけでなく「登録されない」ことも確認するのがポイントです。

記入例：会員登録画面

次の仕様の、パスワードの項目を例にします。

パスワード：必須。8文字以上64文字以下。英字と数字をそれぞれ1文字以上含む。

REG-018とREG-019のように、テストケースを考える中で、仕様が決まっていない点が見つかることがあります。これはテスト仕様書を作る大きな価値の1つです。見つけたら、実施の前に設計者や顧客に確認し、仕様書にも反映します。

テストケースを洗い出す4つの技法

「思いついたものを書く」だけでは、漏れが出たり、同じようなケースばかり増えたりします。次の技法を使うと、少ない件数で、漏れなくテストケースを作れます。

1. 同値分割

入力値を、同じ結果になるグループ（同値クラス）に分け、各グループから代表の値を1つずつ選ぶ方法です。

同じグループの値は同じ動きをするはずなので、20文字で確認できれば、30文字や40文字を個別に確認する必要はありません。

2. 境界値分析

不具合は、グループの境目で起きやすいことが知られています。「8文字以上」を「8文字より大きい（>）」と実装してしまう、といった間違いです。そこで、境目とその両隣をテストします。

同値分割と組み合わせるのが基本です。記入例のREG-011〜014は、この考え方で作っています。

3. デシジョンテーブル

複数の条件の組み合わせで結果が変わる場合に使います。次の送料の仕様を例にします。

通常の送料は500円。購入金額が5,000円以上、または会員ランクがゴールドなら送料無料。ただし、離島への配送は常に送料1,500円。

表にすると、条件の組み合わせが漏れなく見えるうえ、「離島でゴールド会員の場合は？」といった仕様のあいまいな点にも気づけます（ここでは「常に1,500円」なので、ケース5にまとめています）。

4. 状態遷移

状態によって、できる操作が変わる機能に使います。注文の例です。

表のすべてのマス（できる操作と、できない操作の両方）がテストケースになります。「発送済みの注文をキャンセルしようとしたらどうなるか」のような、できないはずの操作の確認が漏れやすいため、表で洗い出すのが効果的です。

テストの種類による書き分け

単体テストは、JUnitなどの自動テストのコード自体が仕様書の役割を果たすことが多くなっています。その場合も、「どんな観点でテストしたか」を一覧にしておくと、レビューがしやすくなります。

よくある書き方の改善例

テスト仕様書のレビューチェックリスト

AIを使ってテストケースを作るコツ

AIは、仕様からテストケースの候補を洗い出すのが得意です。

• 仕様をそのまま渡し、技法を指定する：「次の仕様について、同値分割と境界値分析でテストケースを作って。表の列はID・観点・入力値・期待結果」
• 仕様のあいまいな点も挙げてもらう：「テストケースを作る中で、仕様が決まっていない点があれば一覧にして」
• 最終的な判断は人が行う：AIの出力を、業務の知識と照らし合わせてレビューし、不足しているケースを追加する

よくある質問

Q. テストケースは何件くらい必要ですか？ A. 件数に決まりはありません。大切なのは、要件と観点の網羅性です。同値分割や境界値分析を使うと、件数を抑えながら漏れを減らせます。

Q. Excelとテスト管理ツールのどちらで管理すればいいですか？ A. 小規模ならExcelやスプレッドシートで十分です。件数が多い、複数の人で並行して実施する、実施の履歴を残したい場合は、TestRailやQase、Backlogなどのテスト管理ツールを検討します。

Q. 自動テストがあれば、テスト仕様書は不要ですか？ A. 単体テストは、自動テストのコードが仕様書の役割を果たせます。一方、結合テストやシステムテスト、受け入れテストでは、人が確認する観点や業務のシナリオを文書にしておくことが、顧客との合意やレビューに役立ちます。

まとめ

• テスト仕様書は、誰が実施しても同じ手順・同じ基準で確認できるようにするための文書
• 最も大切なのは期待結果。画面の表示とデータの状態を具体的に書く
• 同値分割・境界値分析で入力値を、デシジョンテーブルで条件の組み合わせを、状態遷移でできる操作・できない操作を洗い出す
• 1行に1つの確認、具体的な入力値、前提条件を書く
• 要件IDで要件とテストを対応づけ、漏れがないかを確認する
• テストケースを作る中で見つかった仕様のあいまいな点は、実施の前に確認する

株式会社RJCでは、要件定義からテストまで、品質を作り込むための考え方を仲間と学び合っています。こうした知識を共有しながら、一緒に成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。