ユースケーステストとは？基本・代替・例外フローの設計方法＋Playwright実装

ユースケーステストとは、ユーザーが目的を達成するまでの一連の操作フロー（ユースケース）をテストシナリオに変換するテスト設計技法です。E2Eテストのシナリオ設計・リグレッションテストの優先度付けに特に効果を発揮します。

ユースケーステストを使うと「ユーザーが実際に行う操作」をそのままテストシナリオに変換でき、「動作はするが使えない」というユーザー目線のバグを根こそぎ発見できます。

「単体テストは全部通っているのに、実際に使ってみたら動かない」「正常系しかテストしていなくて、ユーザーが取りそうな操作のバグが本番で発生した」——こうした問題はユーザー目線のテスト設計が不足していることが原因です。

• 単体テストや機能テストだけでは「ユーザーの操作フロー全体」が検証できない
• 正常系（基本フロー）しかテストしておらず、代替フロー・例外フローが見落とされる
• テストシナリオがエンジニアの視点で作られており、実際のユーザー操作と乖離している

ユースケーステストはこうした問題を解決する技法です。この記事では概念から具体的なシナリオ設計・Playwright E2Eテストへの応用まで一気通貫で解説します。

ユースケーステストとは？

ユースケーステストとは、「ユーザーがシステムを使って目的を達成するまでの一連の操作フロー（ユースケース）」をテストシナリオに変換するテスト設計技法です。

例えば「商品を購入する」というユースケースなら、ログイン→商品選択→カート追加→決済情報入力→注文確定→完了確認という一連のフローをそのままテストシナリオにします。ユーザーの視点からシステムを検証するため、単体テストでは発見できない「フロー全体で初めて現れるバグ」を見つけられます。

状態遷移テストとの違いとは？

同じ「フローをテストする」技法でも、ユースケーステストと状態遷移テストでは視点と目的が異なります。実務では混同されやすいため整理しておきます。

ユースケーステストとE2Eテストの違いとは？

よく混同される2つの概念ですが、役割がまったく異なります。

ユースケーステストの基本構造とは？

ユースケーステストは「基本フロー」「代替フロー」「例外フロー」の3つで構成されます。

実例①：商品購入ユースケースのテスト設計

ECサイトの「商品を購入する」ユースケースを基本フロー・代替フロー・例外フローに分けてテストシナリオを設計します。

基本フロー（正常系）

代替フロー（正常だが別経路）

例外フロー（エラー・異常）

実例②：会員登録ユースケースのテスト設計

もう一つの代表的なユースケース「会員登録する」のテスト設計です。

Playwright × pytestへの応用

ユースケーステストで設計したシナリオはPlaywright × pytestのE2Eテストに直接変換できます。1ユースケース＝1テストファイルの構成が実務のベストプラクティスです。

フォルダ構成の例

tests/
├── conftest.py
└── e2e/
    ├── test_purchase.py        # ユースケース：商品を購入する
    ├── test_register.py        # ユースケース：会員登録する
    └── test_login.py           # ユースケース：ログインする

test_purchase.py：商品購入ユースケースのE2Eテスト

import pytest
from playwright.sync_api import Page, expect

# ── 基本フロー ──────────────────────────────────
def test_purchase_basic_flow(logged_in_page: Page):
    """基本フロー：ログイン済みユーザーが商品を購入する"""
    # Step 2: 商品を選択
    logged_in_page.goto("localhost:3000/products/1")
    expect(logged_in_page.locator("h1.product-title")).to_be_visible()

    # Step 3: カートに追加
    logged_in_page.click("#add-to-cart")
    expect(logged_in_page.locator(".cart-badge")).to_have_text("1")

    # Step 4: 購入手続きへ
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.click("#checkout-btn")

    # Step 5: 注文確定
    logged_in_page.fill("#card-number", "4111111111111111")
    logged_in_page.fill("#expiry", "12/26")
    logged_in_page.fill("#cvv", "123")
    logged_in_page.click("#confirm-order-btn")
    expect(logged_in_page.locator(".order-complete")).to_be_visible()

# ── 代替フロー ──────────────────────────────────
def test_purchase_with_coupon(logged_in_page: Page):
    """代替フロー：クーポン適用して購入する"""
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.fill("#coupon-input", "DISCOUNT10")
    logged_in_page.click("#apply-coupon-btn")
    # クーポン適用後の金額が正しいか確認
    expect(logged_in_page.locator(".discount-amount")).to_be_visible()

# ── 例外フロー ──────────────────────────────────
def test_purchase_payment_failure(logged_in_page: Page):
    """例外フロー：決済失敗時にエラーメッセージが表示されカートが保持される"""
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.click("#checkout-btn")
    # 無効なカード番号で決済
    logged_in_page.fill("#card-number", "0000000000000000")
    logged_in_page.click("#confirm-order-btn")
    # エラーメッセージが表示されるか
    expect(logged_in_page.locator(".payment-error")).to_be_visible()
    # カートの中身が保持されているか
    expect(logged_in_page.locator(".cart-badge")).to_have_text("1")

⚠️ ユースケーステストでよくある失敗パターン4選

実務でユースケーステストを設計するときに陥りやすい失敗を紹介します。

FAQ

📋 この記事のまとめ

ユースケーステストの最大の価値は「ユーザーが実際に行う操作」を起点にすることで、単体テストでは発見できない「フローをまたいだバグ」を体系的に発見できる点です。まず身近なサービスの「商品を購入する」「会員登録する」というユースケースから基本フロー・代替フロー・例外フローを書き出してみましょう。