テストケースとは？書き方・作成手順と実例をQAエンジニアが解説

テストケースとは、ソフトウェアが正しく動作するかを確認するための「検証手順書」です。本記事では、テストケースの書き方・作成方法・実務で使える設計のコツを実例つきで解説します。「何を書けばよいかわからない」「正常系しか思いつかない」「人によって内容がバラバラになる」といった悩みをお持ちの方にも参考にしていただける内容です。

「なんとなく試してみる」テストと、テストケースに基づいた設計テストでは、バグ検出率もチーム間の再現性もまったく異なります。テストケースの書き方を押さえることが、品質保証の入口です。

テストを実施するとき、「どこから手をつければいいかわからない」「テストした内容が人によってバラバラ」「同じバグを何度も見逃す」といった問題は、多くの現場で起きています。

こうした問題の根本にある原因のひとつが、テストケースの設計が曖昧なことです。テストケースを正しく書けるようになると、バグの見逃しが減り、チームでのレビューもしやすくなります。

テストケースとは？定義と役割

テストケースとは、「特定の条件下でソフトウェアの動作を検証するための、手順と期待結果を定義した文書」です。

簡単に言い換えると、次のような問いに答えるセットです。

テストケースがあることで、次のような効果が期待できます。

• 誰が実行しても同じ内容をテストできる（再現性）
• 何をテストしたか・していないかが明確になる（追跡可能性）
• バグが再発したとき、どのテストが漏れていたかを特定しやすくなる
• 新しいメンバーが参加してもすぐにテストを引き継げる

テストケースの構成要素

テストケースに含める項目はプロジェクトやツールによって異なります。以下が基本構成です。

規模の大きいプロジェクトでは以下の項目が加わることもあります。

テストケース管理ツール早見表

管理ツールの選択は、チームの規模や運用スタイルによって変わります。

テストケースの作成手順

テストケースを作成する際には、以下の手順を踏むと、漏れや重複を防ぎやすくなります。

ステップ1：テスト対象の仕様を把握する

まず仕様書・要件定義書・受け入れ条件（ACs）を読み込みます。「どんな入力に対して、何が起きるべきか」の条件を洗い出すことが出発点です。仕様が曖昧な箇所は、テストケースを書く前に開発者や PO に確認しておくと、手戻りを防げます。

ステップ2：テストすべきパターンを分類する

仕様から、テストすべきパターンを「正常系・異常系・境界値」の3つに分類します（詳細は後述）。この分類があると、テストケースの抜け漏れを見つけやすくなります。

ステップ3：テストケースを書く

分類したパターンごとに、「前提条件・操作手順・期待結果」を具体的に記述します。このとき、1テストケース＝1確認ポイントの原則を守ることが重要です。複数の確認を1つにまとめると、どこでFailしたか特定しにくくなります。

ステップ4：レビューを受ける

作成したテストケースは自己チェックだけでなく、別の人にレビューしてもらうと抜け漏れを発見しやすくなります。「この手順で本当に再現できるか」「期待結果は具体的か」の2点を中心に確認してもらいましょう。

ステップ5：実行・結果を記録し、必要に応じて更新する

テストケースは作って終わりではなく、実行結果（Pass/Fail）を記録し、仕様変更があれば更新します。古くなったテストケースは「テストした気になるだけ」で、実際には品質を担保できていないことがあるため注意が必要です。

テストケースの書き方【良い例・悪い例】

同じ「ログイン機能のテスト」でも、書き方によって品質が大きく変わります。

❌ 悪いテストケースの例

問題点：

• 「ログインする」という手順では、何を入力するのか他の人が再現できない
• 「ログインできる」では、どの画面に遷移すれば合格なのか判断できない
• 前提条件がないため、テストユーザーが存在しない環境では実行できない

✅ 良いテストケースの例

改善ポイント：

• テスト名に「正常系」と分類を明記し、テストの意図が一目でわかる
• 前提条件に具体的なユーザー情報を記載し、誰でも再現できる
• 操作手順を番号で細分化し、どのステップでFailしたか特定しやすい
• 期待結果に「遷移先URL」と「表示テキスト」を具体的に書き、判定基準が明確

正常系・異常系・境界値の分類

テストケースを作成するとき、「正常系・異常系・境界値」の3つに分類して考えると、網羅性が高まります。

テストケース作成でよくある失敗パターン

15年以上の現場経験で繰り返し見てきた失敗を4つ紹介します。

自動テスト（pytest）へのテストケース適用

この章のサンプルコードはGitHubでも公開しています：github.com/YOSHITSUGU728/automated-testing-portfolio

テストケースから自動テストまでの流れ

テストケースは設計で終わりではなく、pytestに落とし込むことで自動テストとして継続的に活用できます。

pytest parametrize でテストケース表をコード化する

作成したテストケース一覧は、pytestの @pytest.mark.parametrize を使ってそのままコード化できます。ここではログインフォームの入力バリデーション関数を例に、テストケース表とコードの対応を示します。

import pytest

def validate_login_form(email: str, password: str) -> dict:
    """ログインフォームの入力バリデーション（形式・文字数チェックのみ）

    ※ 実際の認証処理（DB照合・セッション発行）は行わない。
       入力値の形式チェックを行うユーティリティ関数。
    """
    if not email or not password:
        return {"success": False, "message": "メールアドレスとパスワードを入力してください"}
    if "@" not in email:
        return {"success": False, "message": "メールアドレスの形式が正しくありません"}
    if len(password) < 8:
        return {"success": False, "message": "パスワードは8文字以上で入力してください"}
    return {"success": True, "message": "入力値は有効です"}

# テストケース一覧をそのままパラメータに変換
@pytest.mark.parametrize("test_id, email, password, expected_success, expected_message", [
    # 正常系（有効な入力形式）
    ("TC-FORM-001", "test@example.com", "Password123", True,  "入力値は有効です"),
    # 異常系：空欄
    ("TC-FORM-002", "",                "Password123", False, "メールアドレスとパスワードを入力してください"),
    ("TC-FORM-003", "test@example.com", "",            False, "メールアドレスとパスワードを入力してください"),
    # 異常系：メール形式不正
    ("TC-FORM-004", "invalid-email",   "Password123", False, "メールアドレスの形式が正しくありません"),
    # 境界値：パスワード文字数（仕様：8文字以上）
    ("TC-FORM-005", "test@example.com", "Pass123",    False, "パスワードは8文字以上で入力してください"),  # 7文字（下限-1）
    ("TC-FORM-006", "test@example.com", "Pass1234",   True,  "入力値は有効です"),                       # 8文字（下限境界値）
])
def test_login_form_validation(test_id: str, email: str, password: str,
                               expected_success: bool, expected_message: str) -> None:
    result = validate_login_form(email, password)
    assert result["success"] == expected_success, f"[{test_id}] success の期待値が異なります"
    assert result["message"] == expected_message, f"[{test_id}] message の期待値が異なります"

FAQ

📋 まとめ

テストケースの品質は、そのままテスト全体の品質に直結します。まずは身近な機能（ログイン・フォームバリデーションなど）のテストケースを一度書いてみることで、設計の感覚が身についていきます。テストケースがある状態とない状態では、チームのレビュー効率とバグ検出率が大きく変わることを実感できるはずです。