「テストシナリオ」と「テストケース」は同じ意味で使われることがありますが、実際は異なります。これらを混同すると、テスト計画が曖昧すぎて実行できなかったり、詳細すぎて読みにくくなったりします。一方は「何をテストするか」を記述し、もう一方は「どのようにテストするか」を正確に記述します。この関係を正しく理解することで、テストカバレッジは監査可能かつ実行可能になります。
このガイドでは、それぞれの用語を定義し、その違いを並べて説明し、Apidog を使用した実際のAPIテストワークフローでこれらがどのように連携するかを示します。
テストシナリオとは？
テストシナリオとは、テストする価値のあるものを高レベルで記述したものです。正確な手順、入力、期待値を指定することなく、動作や条件を命名します。
見出しのようなものだと考えてください。Eコマースのチェックアウトの場合、シナリオは次のようになります。
- 保存されたカード情報を持つ登録ユーザーのチェックアウトを検証する
- ゲストユーザーのチェックアウトを検証する
- 購入中に商品が在庫切れになった場合のチェックアウトを検証する
- 支払いが拒否された場合のチェックアウトを検証する
各行は、何を検証すべきか、そしてそれがビジネスにとってなぜ重要なのかを伝えます。どのエンドポイントを呼び出すか、どのようなペイロードを送信するかは、ここでは何も示されていません。シナリオはユーザーまたは要件の視点から書かれているため、プロダクトマネージャーとエンジニアの両方にとって読みやすいものとなります。
シナリオは、「動作すべきことすべてを考慮したか？」という一つの問いに答えます。それらはカバレッジマップです。シナリオが欠けている場合、いくら詳細なテストケースを作成しても、そのギャップを埋めることはできません。
テストケースとは？
テストケースとは、シナリオの下に位置する具体的で実行可能なチェックです。正確な入力、前提条件、アクション、そして期待される結果を、二人の人が実行しても同じ結果が得られる十分な精度で指定します。
例えば、「ゲストユーザーのチェックアウトを検証する」というシナリオを考えてみましょう。これは以下のようなケースに分解されます。
- 有効なゲストペイロードで
POST /ordersを実行すると201とorder_idが返される - 配送先住所なしで
POST /ordersを実行すると400とvalidation_errorが返される - 在庫切れのSKUで
POST /ordersを実行すると409とerror: out_of_stockが返される
各ケースは、エンドポイント、ボディ、期待されるステータス、および期待されるレスポンスフィールドを明記します。これは自動化するのに十分な具体性を持っています。ケースの詳細なフィールドごとの構造を知りたい場合は、APIテストケースの書き方でテンプレートが詳細に説明されており、テストケース vs テストスクリプトで実行可能なコードがどこに位置するかが明確にされています。
テストケースの決定的な特徴は精度です。「チェックアウトが機能する」はせいぜいシナリオの断片に過ぎません。「有効なゲスト注文をPOSTし、空ではない order_id と共に201を期待する」がテストケースです。
主な違い
これら二つの概念はいくつかの側面で異なります。この表は簡潔にまとめたものです。
| 側面 | テストシナリオ | テストケース |
|---|---|---|
| レベル | 高レベル、何をテストするか | 低レベル、どのようにテストするか |
| 詳細度 | 簡潔、一行 | データ付きでステップバイステップ |
| 焦点 | ビジネスまたは機能目標 | 技術的実行 |
| 入力 | 指定しない | 正確なペイロードとパラメータ |
| 期待される結果 | 暗黙的 | 正確に記述（ステータス、ボディ、タイミング） |
| 対象者 | プロダクト、QA、エンジニアリング | テスターと自動化ツール |
| 数 | 機能ごとに少数 | シナリオごとに多数 |
| 作成時期 | テスト計画中 | シナリオ合意後 |
関係は階層的です。一つのシナリオから複数のケースが生成されます。シナリオはカバレッジの広さを管理し、ケースは深さと厳密さを管理します。よくある失敗は、シナリオマップがない状態で何十もの詳細なケースを作成することです。これでは、その機能が完全にカバーされているのか、それとも一部だけを集中的にテストしているのかを判断することができません。
別の見方をすると、シナリオは「カバー済み」または「未カバー」とマークできます。テストケースは「合格」または「不合格」としかマークできません。品質を管理するには、両方の状態が必要です。
シナリオとケースが連携する方法
実践的なワークフローは、5つのステップで広範なものから具体的なものへと移行します。
1. 要件からシナリオを特定する。 仕様書またはAPIドキュメントを読み、アンハッピーパスを含め、検証する価値のあるすべての動作をリストアップします。ここでカバレッジの不足が発見されるため、十分に時間を費やしてください。
2. 各シナリオの目的を定義する。 「完了」とは何を意味するのかを明確にします。「ゲストチェックアウトを検証する」の場合、目的は、ゲストが注文を完了して確認を受け取ることができ、無効な注文はきれいに拒否されることです。
3. 各シナリオの下にテストケースを作成する。 各シナリオを入力と期待される結果を持つ具体的なケースに展開します。ハッピーパス、すべてのバリデーション失敗、および関連するエッジ条件をカバーします。
4. 完了性をレビューする。 ツリーを遡って確認します。すべてのシナリオに少なくとも1つのハッピーパスケースと1つのネガティブケースがありますか？すべての文書化されたステータスコードが、何らかの期待される結果に現れていますか？ここで見つかるギャップは修正が容易ですが、本番環境で見つかるギャップはそうではありません。
5. 実行と結果の追跡。 ケースを実行し、ケースごとの合格と不合格を記録し、その結果をシナリオレベルに集約することで、関係者が単に緑色のチェックマークの数だけでなく、カバレッジを確認できるようにします。
ビヘイビア駆動のチームにとって、シナリオはGherkinのGiven-When-Then形式に自然にマッピングされます。BDD APIテストのためのGherkinガイドは、その構造がシナリオを実行可能に保ちつつ、読みやすさを維持する方法を示しています。
具体例：シナリオからケースへ
ノートアプリのAPIを例にとります。テストする価値のある単一の動作は「ユーザーがノートを作成できる」ことです。これがシナリオです。
シナリオ：ユーザーはノートを作成できる。 一行。誰にでも読めるようにテスト計画に含めるものです。エンドポイント、ペイロード、ステータスコードには触れていませんし、触れるべきではありません。
さて、これをケースに展開しましょう。各ケースは、正確な入力と正確な期待される結果を持つ一つの実行可能なチェックです。
- ケース1、ハッピーパス。
{"title": "Groceries", "body": "milk, eggs"}と有効なトークンを使用してPOST /notesを実行します。201、空ではないid、Groceriesと等しいtitle、およびcreated_atタイムスタンプを含むレスポンスボディを期待します。レスポンスは600ミリ秒以内。 - ケース2、必須フィールドの欠落。
{"body": "milk, eggs"}と有効なトークンを使用してPOST /notesを実行します。400、validation_errorと等しいerror、およびtitleフィールドを指すdetailsを期待します。 - ケース3、認証なし。 有効なボディとトークンなしで
POST /notesを実行します。401、およびレスポンスにidがないことを期待します。 - ケース4、過大なペイロード。 2MBの
bodyでPOST /notesを実行します。413と明確なエラーメッセージを期待します。
一つのシナリオ、四つのケース。シナリオは何をすべきかを伝え、ケースはどのようにすべきかを、どのテスターや自動実行ツールでも同じ結果を出す十分な精度で伝えました。後で「ユーザーがノートにファイルを添付できる」という機能を追加した場合、それは新しいシナリオとなり、独自のケースセットを生成します。計画は、単なるチェックの羅列になるのではなく、構造化され、監査可能な方法で成長していきます。
Apidogでシナリオとケースを構築する
Apidog はこの階層を直接モデル化するため、テスト計画の構造がツール内の構造と一致します。
Apidogにおけるテストシナリオは、それぞれ独自のアサーションを持つAPIリクエストの順序付きシーケンスです。これを視覚的に構築します。動作に関わるエンドポイントを追加し、あるリクエストの出力が次のリクエストに供給されるように連結し（ログインがトークンを返し、次のリクエストがそれを使用するなど）、各ステップにアサーションを設定します。
各リクエストとアサーションのブロックは、実質的にテストケースです。スクリプトを書くことなく、クリックするだけでステータスコード、レスポンスボディのフィールド、スキーマ適合性、レスポンス時間をアサートできます。データ駆動型テストでは、1つのケースをCSVまたはJSONファイルからの多数の入力行に対して実行できるため、1つのネガティブケースで考えられるすべての無効な組み合わせをカバーできます。
シナリオはその後、API全体で整理された繰り返し可能な実行のためにテストスイートにグループ化されます。スイートはローカル、スケジュール、またはCI内で実行でき、Apidogはケースレベルとシナリオレベルの両方で結果を示すレポートを生成します。この二重のビューが成果です。エンジニアはどのケースが失敗したかを確認し、リーダーはどのシナリオがリスクに晒されているかを把握できます。
最初のシナリオを構築し、ケースからシナリオへの集約を実際に確認するには、Apidogをダウンロードしてください。
なぜ片方だけではなく両方が必要なのか
チームは時々、どちらかの層をスキップしようとします。シナリオをスキップしてケースだけを書くと、カバレッジマップのない長く平坦なリストになり、すべてのケースを読み返さなければ「ゲストチェックアウトを完全にテストしたか？」と答えることはできません。ケースをスキップしてシナリオだけを残すと、「チェックアウトを検証する」がテスターごとに異なる意味を持つため、誰も一貫して実行できない計画ができてしまいます。
二つの層はまた、異なる読者に役立ちます。プロダクトマネージャーは、正しいものがテストされていることを確認するためにシナリオを読みます。自動化エンジニアは、実行ツールを構築するためにケースを読みます。合格したケースだけを示すテストレポートは、リーダーシップにカバレッジについて何も伝えませんが、ケースをシナリオに集約したレポートは、どの機能が出荷可能であるかを正確に伝えます。
シナリオは安定させ、ケースは最新の状態に保ちましょう。シナリオは機能の意図が変わったときにのみ変更されます。ケースはAPI契約が変更されるたびに変更されます。これらを別々のライフサイクルを持つ独立した成果物として扱うことで、テスト計画は正確性と保守性の両方を維持できます。
よくある質問
- テストシナリオはテストスイートと同じですか？ 違います。シナリオはテストすべき動作を記述します。スイートは、実行のためにグループ化された実行可能なテストのコレクションです。1つのスイートには、多くのシナリオからのケースを含めることができます。テストスイート vs テストケースを参照してください。
- 1つのシナリオにはいくつのテストケースが必要ですか？ ハッピーパスと、そのシナリオが暗示するすべての失敗モードをカバーするのに十分な数です。単純なシナリオでは3つか4つのケースで済むかもしれませんが、複雑なシナリオではそれ以上必要です。
- シナリオとケースは誰が書くのですか？ シナリオは意図を符号化するため、プロダクトチームとQAが共同で草案を作成することがよくあります。ケースは技術的な詳細を符号化するため、通常はQAまたは開発者が作成します。テストケース仕様書の形式は、ケース作成の一貫性を保つのに役立ちます。
- テストが自動化されている場合でもシナリオは必要ですか？ はい、必要です。自動化はケースを実行しますが、シナリオは「適切なケースが存在するか」という問いに答えます。カバレッジマップのない自動化は、単に失敗を早く見つけるだけです。