テストケースの作り方 記載項目・設計技法・書き方のコツを実例付きで解説

「テストケースを作成するよう依頼されたが、何をどのように書けばよいかわからない」「テストケースを書いたが、抜け漏れを指摘されることが多い」。ソフトウェア開発の現場では、テストケースの作り方に悩むエンジニアは少なくありません。

テストケースとは、テストの実行手順・入力データ・期待する結果などをまとめた文書であり、ソフトウェアの品質を保証するための基盤となるものです。テストケースの精度が低ければ、バグの見落としや手戻りが発生し、プロジェクト全体のコストと納期に影響します。

この記事では、テストケースの基本的な定義から、記載すべき項目、具体的な作成手順、網羅性を高めるためのテスト設計技法、そして品質の高いテストケースを書くためのコツまで、実例を交えて解説します。

確認したいポイント	結論	詳細
テストケースには何を書くのか？	6つの基本項目を記載する	テストケースID・テスト概要・テスト観点・前提条件・操作手順・期待結果の6項目が基本です
テストケースの作成手順は？	4ステップで進める	仕様の理解→テスト観点の洗い出し→テスト技法の適用→テストケースへの落とし込みの順で作成します
網羅性を高めるにはどうするか？	テスト設計技法を活用する	同値分割法・境界値分析・デシジョンテーブルなどの技法を使い、効率的にテストケースを洗い出します
テストシナリオとの違いは？	粒度と目的が異なる	テストシナリオは「何をテストするか」を示し、テストケースは「どうテストするか」を具体的に記述します

この記事でわかること

・テストケースの定義とテストシナリオとの違い

・テストケースに記載すべき6つの基本項目

・テストケースを作成する4つのステップと具体例

・網羅性を高めるテスト設計技法（同値分割・境界値分析など）

・品質の高いテストケースを書くための5つのコツ

＼ システム開発・品質向上のご相談はネクストスケールへ ／ ▶ 相談予約はこちら

テストケースとは？定義とテストシナリオとの違い

テストケースの作り方を理解する前に、テストケースの定義と、混同されやすいテストシナリオとの違いを押さえておきましょう。

テストケースの定義と役割

テストケースとは、ソフトウェアテストにおいて確認すべき内容、テストの前提条件、実行手順、入力データ、期待する結果などをまとめた文書です。テスト実行者（テスター）は、このテストケースに沿ってテストを実行し、期待結果と実際の結果を比較して合否を判断します。

テストケースの役割は大きく3つあります。第一に、テストの実行内容を標準化し、誰がテストしても同じ観点でチェックできるようにすること。第二に、テストの網羅性を可視化し、テスト漏れを防ぐこと。第三に、テスト結果の記録として残し、品質の証跡とすることです。

テストケースの品質がテスト全体の品質を左右するため、作成にあたっては「誰が読んでも迷わず実行できる」レベルの具体性が求められます。

テストシナリオとの違い

テストシナリオとテストケースは、テスト設計のなかで異なる粒度の成果物です。

テストシナリオは「何をテストするか」を大きな単位で記述したものです。たとえば「ログイン機能が正常に動作すること」「カートに商品を追加できること」のように、テストの目的やテスト対象を示します。

一方、テストケースは「どうテストするか」を具体的に記述します。ユーザー名にtest@example.com、パスワードにPass1234を入力し、ログインボタンを押下するとトップ画面に遷移すること、のように操作の手順・入力データ・期待結果まで落とし込みます。

つまり、テストシナリオが上位概念であり、1つのテストシナリオに対して複数のテストケースが紐づくという関係です。テストシナリオだけではテスト実行ができないため、必ずテストケースレベルまで具体化する必要があります。

テストケースに記載すべき6つの基本項目

テストケースに必要な情報が不足していると、テスト実行者が判断に迷い、テストの品質が低下します。ここでは、テストケースに記載すべき基本項目を6つ紹介します。

テストケースID・テスト概要・テスト観点

1. テストケースID

各テストケースを一意に識別するためのIDです。「TC-001」「LOGIN-01」のように、機能名や通し番号を組み合わせた命名規則を設けておくと、管理がしやすくなります。

2. テスト概要（テストディスクリプション）

そのテストケースで何を確認するかを1〜2文で記述します。「有効なメールアドレスとパスワードでログインできることを確認する」のように、テストの目的が一読してわかる記述にしましょう。

3. テスト観点

そのテストケースがどの観点（正常系・異常系・境界値など）に該当するかを記載します。テスト観点を明示しておくと、テストケース全体の網羅性を確認する際に役立ちます。

前提条件・操作手順・期待結果

4. 前提条件（テストの事前条件）

テストを実行するために必要な事前の状態や準備を記載します。「テストユーザーのアカウントが作成済みであること」「対象画面が表示されていること」など、テスト開始前に整えるべき条件を明記します。

5. 操作手順（テストステップ）

テストの実行手順を、ステップごとに番号を振って記載します。「1. ログイン画面を表示する → 2. メールアドレス欄にメールアドレスを入力する → 3. パスワード欄にパスワードを入力する → 4. ログインボタンを押下する」のように、1ステップ1操作で記述するのが原則です。

6. 期待結果

テストの操作手順を実行した結果、どのような状態になることが正しいかを記載します。「トップ画面が表示され、画面右上にユーザー名が表示されること」のように、合否を判断できる具体的な基準を示しましょう。

このほかにも、実際のテスト結果（合格・不合格）、不合格時の不具合内容、テスト実行日、テスト担当者などの記録欄を設けておくと、テスト実行後の管理に役立ちます。

＼ システム開発・品質向上のご相談はネクストスケールへ ／ ▶ 資料請求はこちら

テストケースの作り方｜4つのステップで作成する手順

テストケースの作成は、いきなりケースを書き始めるのではなく、段階を踏んで進めることが重要です。ここでは、4つのステップに沿った作成手順を解説します。

ステップ1：仕様書を読み込みテスト対象を理解する

テストケース作成の出発点は、テスト対象の仕様を正確に理解することです。要件定義書や基本設計書、画面設計書などの仕様書を読み込み、テスト対象の機能がどのような入力を受け取り、どのような処理を行い、どのような出力を返すかを把握します。

仕様書の記述が曖昧な部分や、解釈が分かれる部分があれば、この段階で開発者や設計者に確認しておきましょう。仕様の理解が不十分なままテストケースを作成すると、的外れなテストケースが量産されてしまいます。

要件定義の具体的な書き方については、要件定義の例の記事でシステム種類別のサンプルを紹介していますので、参考にしてください。

ステップ2：テスト観点を洗い出す

仕様を理解したら、次にテスト観点（何を確認するか）を網羅的に洗い出します。テスト観点は、テストケースを作成する前の「テスト設計」の段階で整理します。

テスト観点の洗い出しでは、以下のような分類を使うと漏れを防げます。

正常系：仕様どおりの入力を与えた場合に、期待どおりの動作をすることを確認する観点です。

異常系：仕様で想定していない入力（不正な値、空欄、上限超過など）を与えた場合に、適切なエラーハンドリングが行われることを確認する観点です。

境界値：入力値の上限・下限やその前後の値で、正しく動作することを確認する観点です。

組み合わせ：複数の入力項目や条件が組み合わさった場合に、正しく動作することを確認する観点です。

画面表示・遷移：画面のレイアウト、表示内容、画面遷移が仕様どおりであることを確認する観点です。

ステップ3：テスト設計技法を適用してテスト条件を決める

テスト観点が洗い出せたら、テスト設計技法を適用して、具体的なテスト条件（入力値の組み合わせ）を決定します。テスト設計技法については次のセクションで詳しく解説しますが、代表的な技法として同値分割法、境界値分析、デシジョンテーブルなどがあります。

すべての入力値の組み合わせをテストすることは現実的に不可能であるため、テスト設計技法を使って「最小限のテストケース数で最大限のバグ検出効果を得る」ことがポイントです。

ステップ4：テストケースとして文書化する

テスト条件が決まったら、前述の6つの基本項目に沿ってテストケースとして文書化します。テストケースの記述形式は、スプレッドシートやテスト管理ツールを使うのが一般的です。

以下は、ログイン機能のテストケースの記述例です。

ID	テスト概要	操作手順	入力データ	期待結果
TC-001	有効な認証情報でログインできる	1.ログイン画面表示 2.メールアドレス入力 3.パスワード入力 4.ログインボタン押下	メール: test@example.com パスワード: Pass1234	トップ画面に遷移し、ユーザー名が表示される
TC-002	無効なパスワードでエラーが表示される	1.ログイン画面表示 2.メールアドレス入力 3.誤パスワード入力 4.ログインボタン押下	メール: test@example.com パスワード: wrong123	エラーメッセージ「認証情報が正しくありません」が表示される
TC-003	メールアドレス未入力でエラーが表示される	1.ログイン画面表示 2.メールアドレス欄を空欄のまま 3.パスワード入力 4.ログインボタン押下	メール: （空欄） パスワード: Pass1234	エラーメッセージ「メールアドレスを入力してください」が表示される

このように、1行に1テストケースを記載し、各項目を具体的に記述します。テスト実行者が迷わず操作できるよう、操作手順は1ステップずつ記載しましょう。

テストケースの網羅性を高めるテスト設計技法

テストケースの品質を左右するのが、テスト設計技法の活用です。ここでは、実務でよく使われる代表的な技法を4つ紹介します。

同値分割法

同値分割法とは、入力値を「同じ処理結果になるグループ（同値クラス）」に分割し、各グループから代表値を1つ選んでテストする技法です。

たとえば、年齢入力欄の仕様が「1〜120の整数を受け付ける」場合、入力値は次の3つの同値クラスに分けられます。有効な値（1〜120）、無効な値・下限未満（0以下）、無効な値・上限超過（121以上）。各クラスから代表値を1つずつ選んでテストすれば、すべての値を試さなくても主要なケースをカバーできます。

境界値分析

境界値分析とは、同値クラスの境界やその前後の値に着目してテストする技法です。バグは値の境界付近で発生しやすいという経験則に基づいています。

先ほどの年齢入力欄の例では、境界値として0・1・120・121の4つの値をテストします。同値分割法の代表値だけではカバーできない「境界のズレ」によるバグを検出できるため、同値分割法と組み合わせて使うのが効果的です。

IPAが公開しているソフトウェアテストに関する資料でも、同値分割法と境界値分析は基本的なテスト技法として紹介されています（参考：IPA システム構築の上流工程強化）。

デシジョンテーブル（決定表）

デシジョンテーブルとは、複数の条件とそれに対応するアクション（処理結果）の組み合わせを表形式で整理する技法です。条件の組み合わせが複雑な場合に有効で、すべての組み合わせを漏れなく洗い出すことができます。

たとえば、ECサイトの割引条件が「会員かどうか」「購入金額が5,000円以上か」「クーポンを使用するか」の3つの条件で決まる場合、デシジョンテーブルを使えば2の3乗=8パターンの組み合わせを整理できます。

状態遷移テスト

状態遷移テストとは、システムが持つ「状態」と「状態間の遷移」に着目してテストする技法です。注文処理（注文受付→入金確認→出荷→配達完了）や、ユーザーアカウントの状態（未認証→認証済み→ロック中）のように、状態が変化するシステムに適しています。

状態遷移図を作成し、すべての遷移パスを洗い出すことで、特定の状態でのみ発生するバグや、想定外の遷移によるバグを検出できます。

＼ システム開発・品質向上のご相談はネクストスケールへ ／ ▶ 相談予約はこちら

品質の高いテストケースを書くための5つのコツ

テスト設計技法を活用しても、テストケースの書き方が適切でなければ、テスト実行時に問題が発生します。ここでは、実務で役立つ書き方のコツを5つ紹介します。

コツ1：第三者が迷わず実行できる具体性で書く

テストケースは、作成者以外のテスト実行者が読んで迷わず操作できるレベルの具体性が必要です。「正しい値を入力する」のような曖昧な記述ではなく、具体的な入力データを明記しましょう。

悪い例：「正しいユーザー名とパスワードでログインする」

良い例：「ユーザー名欄にtest@example.comを入力し、パスワード欄にPass1234を入力して、ログインボタンを押下する」

コツ2：1テストケースで確認する内容は1つに絞る

1つのテストケースに複数の確認項目を詰め込まないことが原則です。1テストケースに複数の確認が含まれていると、不合格になった場合にどの部分が原因なのか切り分けが難しくなります。

たとえば、「ログインして商品を検索し、カートに追加する」という一連の操作を1テストケースにまとめるのではなく、「ログインできること」「商品を検索できること」「カートに追加できること」をそれぞれ個別のテストケースとして作成しましょう。

コツ3：正常系だけでなく異常系も必ず作成する

正常系のテストケースだけでは、システムの堅牢性を確認できません。異常系のテストケースを意識的に作成することで、不正な入力や想定外の操作に対するエラーハンドリングが正しく機能しているかを確認できます。

異常系の典型的な観点としては、必須項目の未入力、桁数の上限超過、不正な文字種（数値欄への文字入力など）、認証エラー、タイムアウト、同時操作による競合などがあります。

コツ4：期待結果は合否判定が可能な基準で書く

期待結果が「正常に動作すること」のような抽象的な記述では、テスト実行者によって合否の判断が変わってしまいます。期待結果は、客観的に合否を判定できる具体的な基準で記述しましょう。

悪い例：「画面が正しく表示されること」

良い例：「検索結果一覧画面が表示され、検索条件に該当する商品が価格の昇順で最大20件表示されること」

コツ5：テストケースのレビューを必ず実施する

テストケースを作成したら、作成者以外のメンバーによるレビューを必ず実施します。レビューでは、テスト観点の漏れ、テスト条件の過不足、記述の曖昧さ、前提条件の不足などをチェックします。

開発者と一緒にレビューすると、仕様の理解のズレを早期に発見できるため効果的です。また、過去のプロジェクトで発生した不具合のパターンをチェックリスト化しておき、レビュー時に参照するのもおすすめです。

テストの前工程にあたる要件定義書のフォーマットについては、要件定義書のフォーマットの記事で詳しく解説しています。

テストケース作成でよくある失敗とその対策

テストケースの品質が低いと、テスト工程全体の効率と効果が低下します。ここでは、よくある失敗パターンと対策を紹介します。

失敗1：仕様の理解が不十分なままテストケースを作成する

仕様を十分に読み込まずにテストケースを書き始めると、的外れなテストケースが量産される結果になります。「テストしたが不具合が見つからない」のではなく、「不具合がある箇所をテストしていなかった」という状態は、テストの品質が低い典型的なサインです。

対策として、テストケース作成前に仕様書の読み合わせを行い、不明点をすべて解消してからテスト設計に着手しましょう。

失敗2：正常系に偏り異常系のテストケースが不足する

正常な操作だけをテストして満足してしまい、異常系のテストケースが手薄になるケースは非常に多く見られます。実際のバグの多くは、想定外の入力や操作によって発生するため、異常系のカバレッジが低いとリリース後に不具合が頻発します。

対策として、テスト観点の洗い出し段階で「正常系」「異常系」「境界値」のカテゴリを明示し、各カテゴリのテストケース数のバランスをチェックしましょう。

失敗3：テストケースの粒度が粗すぎる

1つのテストケースに多くの確認項目を詰め込むと、テストの実行効率が下がり、不合格時の原因特定が困難になります。テストケースは「1ケース1確認」の粒度で作成するのが原則です。

対策として、テストケースを書いたあとに「このテストケースが不合格だった場合、原因を1つに特定できるか」というチェックを入れましょう。特定できない場合は、テストケースを分割する必要があります。

システム開発のテスト工程を外注する場合は、システム開発の外注とはの記事で、費用相場や外注先の選び方を解説していますので参考にしてください。

＼ システム開発・品質向上のご相談はネクストスケールへ ／ ▶ 資料請求はこちら

まとめ

テストケースは、ソフトウェアテストの品質を決定づける重要な成果物です。テストケースID・テスト概要・テスト観点・前提条件・操作手順・期待結果の6つの基本項目を押さえたうえで、仕様の理解→テスト観点の洗い出し→テスト設計技法の適用→文書化という4つのステップで作成します。

網羅性を高めるためには、同値分割法や境界値分析、デシジョンテーブル、状態遷移テストといったテスト設計技法を適切に活用することがポイントです。また、第三者が迷わず実行できる具体性で記述すること、正常系だけでなく異常系もカバーすること、作成後のレビューを欠かさないことが、品質の高いテストケースを書くためのコツです。

テストケースの品質が上がれば、バグの検出率が向上し、手戻りの削減やリリース後の品質トラブルの防止につながります。本記事の内容を参考に、実務でのテストケース作成に役立てていただければ幸いです。