/note/tech

テストケースをコードで書かないE2Eテスト ── Claude CodeとPlaywright CLIで実現する自然言語...

要約:

■ 1. 背景と課題

  • ZOZOのカート・決済チームにおいて、E2Eテストの整備に多大なコストが発生していた
  • 課題の内訳:
    • 機能リプレイスに伴い、プロジェクトあたり100件以上のテストケースが発生する
    • 割引・クーポン・ポイント・税計算など複雑な注文金額の手動検証に多くのリソースを要する
    • 従来のPlaywrightによる自動化にはプログラミングスキルが必要で、担当者に依存が生じていた

■ 2. システム構成

  • 主要コンポーネント:
    • Claude Codeエージェント(zozotown-qa-tester): テスト実行全体を管理する
    • Playwright CLI: コマンド経由でブラウザを操作し、スナップショットベースで要素を選択する
    • Agent Skills: 再利用可能な操作手順をMarkdownファイルで定義したもの
    • TypeScript製計算サービス: テストの期待値を算出する
    • カスタムCLI(atlassian-cli、zozo-sql-server-cli): ConfluenceおよびDBへのアクセスを担う

■ 3. 主要技術: スナップショットベースの要素選択

  • CSSセレクタではなく、ページ構造をYAML形式でref番号付きのスナップショットとして取得する
  • AIがスナップショットを解釈して対象要素を特定し、ref番号を用いて操作を行う
  • 小規模なUI変更に対して従来手法より高い耐性を持つ

■ 4. テスト実行フロー

  • 6ステップの実行フロー:
    • ステップ1: Confluenceからテストケースを取得する
    • ステップ2: 期待値を含むテスト計画を生成し、ユーザーの承認を得る
    • ステップ3: テスト環境を準備する
    • ステップ4: Agent Skillsに従い操作を実行する
    • ステップ5: 結果とスクリーンショットを記録する
    • ステップ6: 結果をレポートとして出力する
  • 承認ステップの目的:
    • 実行前に解釈の誤りを防ぐ

■ 5. 検証戦略

  • システム実装とテスト実装を仕様から独立してそれぞれ別に実装する
  • 実装の共通化を避けることで、共通バグの混入を防ぎ、真の検証を可能にする

■ 6. Agent Skillsの設計方針

  • スキルの粒度は、ログインやカート操作など単一の手順単位が最適とされる
  • 未定義の操作が発生した際、自動的に新規リファレンスを生成する自己改善の仕組みを持つ

■ 7. 従来手法との比較

  • テスト形式:
    • コードベース: TypeScript/JavaScriptで記述する
    • Claude + Playwright: 自然言語(Confluence)で記述する
  • テスト作成に必要なスキル:
    • コードベース: プログラミングスキルが必要
    • Claude + Playwright: ドメイン知識のみで作成可能
  • UIへの耐性:
    • コードベース: 低い
    • Claude + Playwright: 高い

■ 8. 実績と効果

  • プロジェクトあたり約20〜70件のテストケースを実行する
  • PCとSP(スマートフォン)のバリアントを並行して実行する
  • 複雑な計算検証における手動作業の負担が大幅に軽減された
  • リファレンスの自己改善により、将来のテスト作成が加速する