[ECサイトのテスト自動化落とし穴]出品と購入、リトライの落とし穴

こんにちは。SODAでクオリティエンジニアをやっているokauchiです。
今回は、出品から購入までの一連の流れをE2Eテスト自動化した時の失敗談をお話しします！

出品から購入までのテストシナリオ作成

ECサイトのテスト自動化において、出品から購入までの一連の流れをテストするシナリオはとても重要です。なぜなら、このシナリオはECサイトの中核となる機能を確認し、ユーザーが実際に行う操作をトレースすることで、より実際の出品・購入体験に近いテストを行うことができるからです。

以下に、基本的なテストシナリオの例を挙げます。

1. 商品出品:
   • 管理画面にログインし、商品を新規出品する。
   • 商品のタイトル、説明、価格、画像などの情報を入力する。
   • 出品が正常に完了したことを確認する。
2. 商品購入:
   • 出品した商品を検索し、商品ページにアクセスする。
   • 商品をカートに追加し、購入手続きに進む。
   • 配送先情報や支払い方法を入力し、購入を完了する。
   • 購入履歴に購入した商品が表示されることを確認する。

これらのシナリオを自動化することで、新機能の追加や既存機能の修正がECサイトの基本的な機能に影響を与えていないかを効率的に確認することができます。

リトライ機能の罠

これらのテストシナリオを実装にあたって、出品と購入のテストシナリオは別々に作成をしました。地産地消をしようとテストシナリオで出品した商品を購入しようと進め、実際にそれらのテストシナリオを運用していくと、予期せぬ問題に直面することがありました。購入後のステップでテストが失敗した際のリトライ機能との相性が最悪でした。

通常、テスト自動化の安定性を高めるために、テストが失敗した場合にリトライを行う機能を実装することがあります。しかし、今回の場合、購入後の特定のステップで失敗した場合、商品の在庫が空になってしまい、リトライが何度行われても必ず失敗するという問題が発生しました。

在庫管理の重要性

この経験から、テストシナリオの目的を明確にし、目的に合わせたテストデータを用意することの重要性を痛感しました。

もしテストシナリオの目的が「出品が行えること」「購入が行えること」だけを確認するようであれば、今出品した商品を購入する必要性はなくなるので、在庫が複数ある商品から購入をすべきです。バッチ処理で定期的に在庫を補充することができればリトライがどのタイミングで何度行われても前提条件が崩れることはありません。

一方で、もしテストシナリオの目的が「今出品をした商品を正常に購入できることを確認すること」なのであれば、リトライが発生しないようにテストシナリオを設計するか、リトライ時の処理が冪等性を持つように改善する必要があります。出品と購入のテストシナリオを結合したテストシナリオを用意する、リトライが起こる確率を出来るだけ下げて、実行時の設定でリトライを0回にする手もあるかも知れません。

まとめ

ECサイトのE2Eテスト自動化は、効率的なテストを行う上で非常に有効です。しかし、テストシナリオの設計やテストデータの準備を適切に行わないと、予期せぬ問題が発生することがあります。

今回の経験を通じて、以下の点を学びました。

• テストシナリオの目的を明確にする。
• どのタイミングでリトライがかかっても前提条件を満たせるテストシナリオを設計・実装する。

これらの教訓を活かし、より効果的なテスト自動化を目指していきたいと思います！