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

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

はじめに

はじめに

こんにちは、カート決済部カート決済サービスAブロックの道場です。ZOZOTOWN内のカート機能や決済機能の開発、保守運用を担当しています。

こんにちは、カート決済部カート決済サービスAブロックの道場です。ZOZOTOWN内のカート機能や決済機能の開発、保守運用を担当しています。

現在、ZOZOTOWNのカート決済画面はリプレイスが進行中です。既存システムとリプレイス後のシステムが並行して開発される中、既存システムへのさまざまな機能改修を、リプレイス側にも取り込む必要があります。その際、条件の組み合わせが膨大になるテストを手動で網羅的に実施することが現実的でなく、特に注文金額の計算結果の正確性を人間が1件ずつ確認するには大きなコストがかかっていました。

現在、ZOZOTOWNのカート決済画面はリプレイスが進行中です。既存システムとリプレイス後のシステムが並行して開発される中、既存システムへのさまざまな機能改修を、リプレイス側にも取り込む必要があります。その際、条件の組み合わせが膨大になるテストを手動で網羅的に実施することが現実的でなく、特に注文金額の計算結果の正確性を人間が1件ずつ確認するには大きなコストがかかっていました。

本記事では、Claude CodeとPlaywright CLIを組み合わせて、自然言語によるE2Eテストを自動化した仕組みをご紹介します。Confluence(Atlassian社が提供するナレッジ共有ツール)に自然言語でテスト手順を記述することでAIが自律的にブラウザを操作し、計算検証も含めてE2Eテストを完結させています。コードを書かずにテストを作成・実行できるため、テスト自動化の属人化解消にもつながりました。

本記事では、Claude CodeとPlaywright CLIを組み合わせて、自然言語によるE2Eテストを自動化した仕組みをご紹介します。Confluence(Atlassian社が提供するナレッジ共有ツール)に自然言語でテスト手順を記述することでAIが自律的にブラウザを操作し、計算検証も含めてE2Eテストを完結させています。コードを書かずにテストを作成・実行できるため、テスト自動化の属人化解消にもつながりました。

目次

目次

背景・課題

背景・課題

リプレイスに伴う二重開発とテストの課題

リプレイスに伴う二重開発とテストの課題

冒頭の通り、ZOZOTOWNのカート決済画面ではリプレイスが進行中です。既存システムとリプレイス後のシステムが並行して動作する期間中、既存システムに対するさまざまな機能改修をリプレイス側へ取り込む必要があります。

冒頭の通り、ZOZOTOWNのカート決済画面ではリプレイスが進行中です。既存システムとリプレイス後のシステムが並行して動作する期間中、既存システムに対するさまざまな機能改修をリプレイス側へ取り込む必要があります。

これらの改修をすべて取り込み、条件の組み合わせが爆発的に増加するテストケースを検証する工数が大きな課題となりました。

これらの改修をすべて取り込み、条件の組み合わせが爆発的に増加するテストケースを検証する工数が大きな課題となりました。

たとえば、ある案件の機能を取り込む場合、以下のような因子が絡み合います。

たとえば、ある案件の機能を取り込む場合、以下のような因子が絡み合います。

  • ユーザーの属性(性別・年齢 等)
  • ユーザーの属性(性別・年齢 等)
  • 購入商品の種類・金額
  • 購入商品の種類・金額
  • 割引・クーポンの有無
  • 割引・クーポンの有無
  • ポイント利用の有無
  • ポイント利用の有無
  • キャンペーン期間の内外
  • キャンペーン期間の内外

これらを組み合わせると、1つの案件だけで100件以上のテストケースが発生することもありました。さらに、各テストケースでは注文フローの複数画面(配送・支払い選択、注文の確認 等)で表示値の確認が必要です。そして、PC用の画面とスマートフォン(以下、SPと表記します)用の画面がそれぞれ存在するため、検証量は実質的にさらに倍になります。

これらを組み合わせると、1つの案件だけで100件以上のテストケースが発生することもありました。さらに、各テストケースでは注文フローの複数画面(配送・支払い選択、注文の確認 等)で表示値の確認が必要です。そして、PC用の画面とスマートフォン(以下、SPと表記します)用の画面がそれぞれ存在するため、検証量は実質的にさらに倍になります。

カート決済画面では、注文金額の計算ロジックにさまざまな要素が関わっており、前述の通り案件ごとに条件の組み合わせが大きくなりがちでした。さらに、期待値は複雑な計算式で決まるため、人間が1件ずつ手計算したうえで画面の表示と照合するには多くの時間がかかっていました。

カート決済画面では、注文金額の計算ロジックにさまざまな要素が関わっており、前述の通り案件ごとに条件の組み合わせ...

开通本站会员,查看完整译文。

- 위키
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-05-27 16:19
浙ICP备14020137号-1 $방문자$