問題17：ユースケーステスト（1）Easytravel の最少テストケース数
問題 #17
Section titled “問題 #17”「Easytravel」は、バスや地下鉄の運賃支払いに使用されるカードです。ユーザーはチャージ機で残高を追加でき、乗車時にカードをリーダーにかざすと自動的に運賃が差し引かれます。
あなたはプロジェクトチームの一員として、以下のユースケースのレビューとテスト設計を任されました。
ユースケース：クレジットカードから残高を追加する（UC-201201）
- アクター: ユーザー、システム
- 事前条件: 有効なEasytravelカードとクレジットカードを所有していること
【メインの振る舞い（基本フロー）】
- ユーザーがカードを挿入する
- システムがメニュー（残高照会、チャージ、履歴確認）を表示する (例外 E1)
- ユーザーが「チャージ」を選択する
- システムが金額を尋ねる (例外 E1)
- ユーザーが金額を選択する
- システムが支払い方法（現金、クレジットカード）を尋ねる (例外 E1)
- ユーザーが「クレジットカード」を選択する
- システムがクレジットカードの挿入を求める (例外 E1)
- ユーザーがクレジットカードを挿入する
- システムが請求額を表示し、確認を求める (例外 E2)
- ユーザーが金額を承認する
- システムが決済を実行し、残高を更新する
- ユーザーがカードを取り出す
- システムがレシートを印刷する
- システムがメイン画面に戻る
【例外フロー】
- E1: ユーザーはカードを取り出すことで、いつでもプロセスを中断できる（ステップ2, 4, 6, 8で発生可能）
- E2: ユーザーが承認しない場合、キャンセルボタンで操作を中止できる（ステップ10で発生可能）
このユースケースに対して「最小のカバレッジ」を達成するために必要なテストケース数はいくつか？
- a) 2 テストケース
- b) 1 テストケース
- c) 9 テストケース
- d) 6 テストケース
d) 6 テストケース
JSTQB AL TA（およびFoundation Level）において、ユースケーステストの「最小のカバレッジ」は、通常、すべての**「シナリオ（Scenario）」**を少なくとも1回実行することを指します。
シナリオとは、ユースケースの開始から終了までの一連のパスのことです。今回のユースケースにおけるシナリオを数え上げると以下のようになります。
- 基本フロー（正常系）: ステップ1から15まで完走するパス（1通り）
- 例外フロー E1（中断）: ステップ2, 4, 6, 8 の各ポイントでカードを取り出すパス（4通り）
- 例外フロー E2（キャンセル）: ステップ10でキャンセルボタンを押すパス（1通り）
これらを合計すると、1（基本） + 4（E1の各ポイント） + 1（E2） = 6通りのシナリオが存在します。したがって、すべてのパスを網羅するための最小テストケース数は「6」となります。
実務でユースケースからテスト設計を行う際、以下の考え方が重要になります。
- シナリオの定義: 多くの組織やシラバスでは、「基本フローを1つ」「代替/例外フローの各分岐を1つずつ」をテストケースとしてカウントします。
- 分岐ポイントの重要性: 同じ内容の例外（今回のE1など）であっても、発生するステップが異なれば、それまでのシステムの状態やデータの保持状況が異なるため、それぞれを独立したシナリオとして検証するのが一般的です。
- カバレッジの深さ: 「最小」は全シナリオの網羅ですが、より高度なテストでは「各条件の組み合わせ」や「異常値の入力」などを追加し、デシジョンテーブルテスト等と組み合わせて網羅性を高めていきます。