ユースケーステスト（Use Case Testing）は、システムとユーザー（または外部アクター）との「実際のやり取り（トランザクション）」をシナリオ形式で記述し、それをもとにテストケースを設計する手法です。
この手法は統合テスト、システムテスト、受け入れテストで特に有効であり、ユーザー操作を中心に欠陥を発見するのに適しています。
🔹 ユースケーステストとは？
ユースケーステストは、「誰が」「何を」「どのように」行うのかを明確にするテスト設計手法です。
ここでいう「アクター（actor）」とは、システムとやり取りをする外部の存在であり、以下のようなものを指します。
-
実際のユーザー（人間）
-
他のシステムや外部デバイス（例：カードリーダー、サーバー）
ユースケースでは、アクターとシステムのやり取りを順を追って記述します。
その結果、インターフェースや統合部分の欠陥を検出しやすいという特徴があります。
🔹 試験でのポイント（Foundationレベルとの違い）
ISTQB Foundation Level でも登場したユースケーステストですが、
Advanced Test Analyst ではさらに一歩進んで、以下の観点が問われます。
-
シナリオからテストケース数を導出できるか？
-
例外（Exception）をどのように扱うか？
-
各ユースケースを独立して評価できるか？
🔹 例題：Easy Travel カードのユースケース
ここでは、試験で出題される代表的なユースケースの例を紹介します。
💡 シナリオ概要
「Easy Travel」という交通系ICカードシステムにおいて、ユーザーがクレジットカードから残高をチャージするプロセスをテストする。
この「Easy Travel」は、地下鉄やバスで利用できる交通カードであり、
専用のチャージ機で残高を追加する仕組みです。
✅ ユースケース情報
-
ユースケースID： UC-201
-
ユースケース名： クレジットカードからEasy Travel残高を追加する
-
アクター： ユーザー、システム
-
前提条件：
-
ユーザーがEasy Travelカードを持っている
-
クレジットカードを所持している
-
🔸 メインシナリオ（成功パターン）
-
ユーザーがカードを読み取り台に置く
-
システムがメニューを表示（「残高照会」「チャージ」など）
-
ユーザーが「チャージ」を選択
-
システムが金額の入力を促す
-
ユーザーが金額を入力
-
システムが支払い方法（現金 or クレジットカード）を尋ねる
-
ユーザーが「クレジットカード」を選択
-
ユーザーがクレジットカードを挿入
-
システムが金額と決済確認を表示
-
ユーザーが決済を承認
-
システムが残高を更新
-
ユーザーがカードを取り外す
-
システムがメインメニューに戻る
この一連の流れが、**正常系（メインフロー）**の1つのユースケースになります。
🔸 例外パターン（Exceptions）
ユースケースでは、途中で異常が発生するパターンも定義します。
この例では、以下の2種類の例外が存在します。
|
例外ID |
タイミング |
内容 |
|---|---|---|
|
E1 |
ステップ1〜8の間 |
ユーザーがカードを取り外して処理を中止した場合 |
|
E2 |
ステップ9〜10の間 |
ユーザーが支払い金額を承認しなかった場合（決済拒否など） |
🔸 テストケース設計
問題文では次のように問われます：
「このユースケースに対して、最小限のカバレッジを達成するために必要なテストケース数はいくつか？」
✅ 考え方：
-
1件目： メインシナリオ（正常完了）
-
4件： 例外 E1（ステップ4、6、8など、カードを抜く可能性のある箇所ごと）
-
1件： 例外 E2（決済拒否）
合計：
👉 6件のテストケース
|
種別 |
テストケース数 |
内容 |
|---|---|---|
|
メインシナリオ |
1 |
正常系の成功パス |
|
例外E1 |
4 |
各ステップでのカード取り外し動作 |
|
例外E2 |
1 |
支払い拒否シナリオ |
|
合計 |
6 |
— |
🧩 ポイントまとめ
-
各ユースケースは固有のIDを持ち、独立してテストされる。
-
メインフローと例外フローを明確に分けて設計する。
-
例外はエラー発生点ごとに別テストケースとして扱う。
-
カバレッジ最小構成を求める問題が試験でよく出題される。
🔹 ユースケーステストの利点
|
項目 |
内容 |
|---|---|
|
現実的なシナリオを基にしている |
実際のユーザー操作に近いため、実用的な欠陥を検出できる |
|
受け入れテストに有効 |
顧客目線での業務シナリオを検証できる |
|
インターフェース不具合の発見 |
システム間・モジュール間のやり取りを確認できる |
🔹 まとめ
ユースケーステストは、単なる「仕様の確認」ではなく、
実際のユーザー行動を再現するテスト設計手法です。
-
メインフロー → 成功の流れ
-
例外フロー → 想定外の中断・拒否シナリオ
を整理し、どのパターンを網羅すべきかを見極めましょう。
🧭 試験対策のヒント
-
「Use Case ID」や「Exception番号（E1, E2）」が与えられた問題では、
1メイン＋n例外 という構成でテストケース数を数える。
-
「Minimum coverage」という表現に注意。
→ すべての例外パスを含める必要があります。
-
同じシナリオの別ユースケースは別IDとして扱う。
コメント