テストケースとは
テストケースは、ソフトウェアアプリケーションの特定の機能が正しく動作することを検証するために使用される条件と手順のセットです。各テストケースは、何をテストするか、どのようにテストするか、期待される結果が何であるかを定義します。
テストケースを QA プロセスの構成要素と捉えてください。うまく書かれたテストケースは反復可能で曖昧さがなく、楽観的なパス（happy path）と境界ケース（edge case）の両方をカバーするため、どのテスターでも手に取って一貫して実行できます。
この記事では、実用的なテストケーステンプレートを提供し、さらに最も一般的なログインと登録のシナリオに基づく実際の例を順を追って説明します。これらのテストケースは楽観的なパスと主要な境界ケースをカバーし、テスト管理ツールにコピーする準備ができています。
テストケーステンプレート
以下は、テスト管理ツール、スプレッドシート、またはドキュメントにコピーできる標準的なテストケーステンプレートです。
Test Case ID: TC-[Module]-[Number]
Module: [例、Login、Registration]
Test Title: [短くて説明的な名前]
Priority: [Critical / High / Medium / Low]
Preconditions: [テスト前に真でなければならないこと]
Test Data: [テスト中に使用する特定のデータ]
Test Steps:
1. [ステップ1]
2. [ステップ2]
3. [ステップ3]
Expected Result:
[手順を正しく実行した場合に何が起こるべきか]
Actual Result:
[実際に起こったこと — テスト実行中に記入]
Status: [Pass / Fail / Blocked / Not Executed]
Bug Reference: [該当する場合の BUG-XXX]
Tester: [名前]
Test Date: [YYYY-MM-DD]
テストケースのフィールドリファレンス
テストケースを書く前に、各フィールドの意味を理解してください:
| Field | Description | Example |
|---|---|---|
| Test Case ID | 一意の識別子: TC-[Module]-[Number] |
TC-REG-001 |
| Module | 属する機能・モジュール | Registration, Login, Password Reset |
| Test Title | シナリオの一行の説明 | Successful registration with valid email and password |
| Priority | 重要度: Critical > High > Medium > Low | Critical = コアフローが壊れている; High = 主要な問題; Medium = 境界ケース; Low = 見た目のみ |
| Preconditions | テスト前に真でなければならない状態 | User is on the registration page, email is not registered |
| Test Data | テスト中に使用する特定の値、正確な文字列 | email = "<user@example.com>" |
| Test Steps | 番号付きの操作、操作ごとに1ステップ | 1. Navigate to URL; 2. Enter value; 3. Click button |
| Expected Result | 正しく実行された場合に何が起こるべきか | Account created, redirected to dashboard |
| Actual Result | 実際に起こったこと — 実行中に記入 | Same as expected / Error: "Email already exists" |
| Status | Pass / Fail / Blocked / Not Executed | Filled in during execution |
| Bug Reference | 関連するバグ追跡 ID（該当する場合） | BUG-0042 |
| Notes | 追加情報: 回避策、関連チケット | Only reproducible in Firefox |
完全な例
テンプレートがどのように記入されるかを示す、1つの完全なテストケースを紹介します:
Test Case ID: TC-REG-001
Module: User Registration
Test Title: Successful registration with valid email and password
Priority: Critical
Preconditions: ユーザーは登録ページにいて、このメールでの既存アカウントがない
Test Data: email = "newuser@example.com", password = "SecurePass123!", name = "John Doe"
Test Steps:
1. https://app.example.com/register に移動
2. Full Name フィールドに "John Doe" を入力
3. Email フィールドに "newuser@example.com" を入力
4. Password フィールドに "SecurePass123!" を入力
5. Confirm Password フィールドに "SecurePass123!" を入力
6. "I agree to Terms of Service" チェックボックスをオン
7. "Create Account" ボタンをクリック
Expected Result:
- アカウントが正常に作成される
- ユーザーが「メールを確認してください」ページへリダイレクトされる
- 30秒以内に newuser@example.com 宛に確認メールが送信される
- メール確認後、登録した資格情報でログインできる
テストケース表（コピー＆ペースト対応）
この表を Excel / Google Sheets / TestRail に直接コピーしてください。最初の5列にはサンプルデータが事前に記入されています。残りの列はテスト実行中にあなたが記入するためのものです。
| ID | Module | Test Title | Priority | Type | Preconditions | Test Steps | Test Data | Expected Result | Actual Result | Pass/Fail | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TC-REG-001 | Registration | Successful registration with valid email and password | Critical | Happy Path | User on registration page, email not registered | 1. Go to /register 2. Enter name, email, password 3. Agree to terms 4. Click Create | email="<newuser@example.com>", password="SecurePass123!" | Account created, redirected to verify page, confirmation email sent within 30s | |||
| TC-LOGIN-001 | Login | Successful login with correct email and password | Critical | Happy Path | Verified account <user@example.com> exists | 1. Go to /login 2. Enter email 3. Enter password 4. Click Sign In | email="<user@example.com>", password="CorrectPass123!" | Authenticated, redirected to dashboard, session token set |
空白のテンプレート表
以下は空白の表ヘッダーです。コピーして、独自のテストケース用の行を追加してください:
| ID | Module | Test Title | Priority | Type | Preconditions | Test Steps | Test Data | Expected Result | Actual Result | Pass/Fail | Notes |
|---|
優れたテストケースの書き方: ベストプラクティス
1. 各テストケースを独立させる
テストケースは1つの特定の動作を検証すべきです。失敗した場合、何が壊れているのかを正確に把握できるはずです。1つのテストケースに複数のシナリオを組み合わせないでください。
2. テストデータを具体的にする
「有効なメールを入力」は曖昧です。「<user@example.com> を入力」は正確です。具体的なテストデータにより、テストケースは再現可能になります。
3. 楽観的なパスと境界ケースの両方をカバーする
楽観的なパス（有効なデータでの正常なログイン）は重要ですが、境界ケースは実際のバグを明らかにします:
- 空のフィールド
- 無効な形式
- 境界値
- 期限切れトークン
- 同時セッション
4. 事前条件（preconditions）を書く
事前条件はテスト環境を準備します。それがないと、テスターが間違った状態から始めて、誤った合格・不合格を得る可能性があります。
5. 明確で番号付きの手順を使用する
各ステップは単一の操作にすべきです。「フォームを記入して送信」は曖昧すぎます。個々のフィールド入力に分解してください。
6. 期待される結果を詳細に含める
「ログインが成功する」では不十分です。ユーザーが何を見るか、どこへリダイレクトされるか、どのメールが送信されるか、データベースで何が起こるかを指定してください。
テストケース実行での BugCapturer の活用法
テストケースを実行するとき、テスターは結果を迅速に記録する必要があります。バグレポートと視覚的フィードバックのための無料 Chrome 拡張機能である BugCapturer は、この部分をシームレスにします:
- 注釈付きスクリーンショット: テストケースが失敗したとき、問題を強調する矢印とテキストでページの正確な状態を取得 — 言葉で説明する必要はありません。
- 画面録画: 複雑なシナリオ（例: タイミング問題を伴う複数ステップのログインフロー）では、テスト実行全体を短い WebM 動画で録画します。
- 技術メタデータの自動取得: URL、ブラウザ、OS、画面解像度、ビューポートが自動的に取得されます。環境固有のバグを再現するために重要です。
- 診断データ: コンソールエラーと失敗したネットワークリクエスト（HTTP ステータス ≥ 400）が視覚的証拠とともに取得されます。ネットワーク URL は、機密パラメータが自動的にマスキングされます。
- Excel/TSV エクスポート: 構造化バグレポート行をワンクリックでクリップボードにコピー。テスト管理ツールやチームのスプレッドシートに直接貼り付けられます。
これにより、テスターはバグレポートを書く時間を減らし、テストケースの実行により多くの時間を費やせます。
ダウンロード: テストケーステンプレート
上記のテンプレートと例を好みの形式にコピーしてください:
- TestRail / Zephyr / Xray — 標準フィールドを持つテストケースを作成
- Excel / Google Sheets — 各フィールドの列を持つスプレッドシートとして使用
- Notion / Confluence — テストケースごとに1エントリのデータベースを作成
- Markdown — バージョン管理のためにリポジトリに保持
この記事のテンプレートと例はすぐに使用できます。ログイン・登録シナリオをアプリケーションに合わせてカスタマイズし、独自のモジュールを追加して、QA チームが自信を持って実行できる完全なテストスイートを構築してください。