ノーコードツールからPlaywrightに移行して半年の振り返り

ツール導入前の課題

導入前に使用していたノーコードのE2Eテストツールには、大きく2つの課題がありました。
まず、従量課金制のため実行回数に比例してコストが上昇する点。事業の成長と共にテストの実行頻度を上げたいニーズは高まる一方、コストを気にして実行を躊躇してしまう状況がありました。

そして、ノーコードツールでありながら、実際の運用ではコードでなければ対応できない場面が頻繁に発生する点。複雑なUIに対するロケータ取得、APIの取得結果による条件分岐など、ノーコードの枠組みだけでは対応しきれないケースが多く、「ノーコードのシナリオ＋補完用のコード」という二重管理が生まれ、運用が煩雑になっていました。最初からコードで一元管理した方がシンプルで効率的なのでは？と感じていました。

• Autify
• MagicPod

• 費用(月額などの固定費 + 実行回数による従量課金)
• 実行環境の可搬性

ツール移行には相応のコストがかかりますが、以下の理由から長期的なメリットがあると判断しました。

移行を決断した理由

ランニングコストの削減に加え、コードベースでの一元管理による保守性向上、実行速度の大幅改善、環境の可搬性向上など、移行コストを払ってでも得られるメリットが大きいと判断しました。

改善したかった課題はどれくらい解決されたか

• 実行コストを抑えられ、必要な時にテストを回せるようになった
• 実行速度は平均で88%向上
• コードベースでの柔軟かつ一元的な管理を実現

どのような成果が得られたか

• 実行タイミングがリリース直前のみでしたが、追加で日次実行を実施しています。その結果、不具合の検知数が向上し、以前よりも効率的に開発改修を取り込めるようになりました。
• STG環境のみでの実施でしたが、環境の可搬性が向上したことにより、DEV、feature環境でも実施できる状態となりました。まだ運用を開始したばかりですが、feature環境でのQAテスト開始時に実行することで、開発改修のタイミングで早期に不具合を検知することを目指しています。

実装リソースの確保

コードベースのPlaywrightでテストを実装するには、当然ある程度のプログラミングスキルが必要なので、自分1人のリソースだけでは全テストの移行を完了させるのが難しい状況でした。実装スキルがあり、かつ業務ドメイン知識も把握しているメンバーにヘルプに来てもらうことで解決しました。

環境差分や並列実行によるフレーキーテストの増加

DEV、STG、Feature環境での挙動の違いや、並列実行時の競合状態によってテストが不安定になるケースが発生しました。タイムアウト時間の調整やロケーターの微調整を繰り返し行い、安定化を図りました。

既存ツールとの並行運用

移行期間中は両方のツールを維持する必要があり、かなり大変でした。並行運用をする場合は、移行のマイルストーンにはバッファを多めに持たせる必要があると思います。

判断軸を明確にしておく

「なぜこのツールを選ぶのか」「導入によって何を実現したいのか」この目的を明確にしておくと、プロジェクトの途中で迷った時に助かります。コスト、保守性、実行速度、現場ごとに重視する点は違うはずです。

事前検証は念入りに行う

既に他のツールを使用している場合は、現在の機能が新しいツールでも再現できるか確認が重要です。新規導入の場合でも、想定しているテストシナリオが実現可能かを事前に検証しておくことをお勧めします。

完璧を求めすぎない

最初から100点満点の設計を目指すと、時間がいくらあっても足りません。「まずは導入をやりきること」をゴールに設定し、段階的に改善していくアプローチが、結果的にツール導入の成功へ繋がります。

既存のツールから移行して半年程度経過しましたが、メンテナンスに手こずりながらも運用を継続しています。継続したことで、蓄積されたデータを基にフレーキーテストの傾向なども把握できるようになってきました。Playwrightをメンテナンスすることで、プロダクト側の作りの問題も発見することができ、とても良かったです。

今後は、LLMを用いてより広範囲のリグレッションテストの自動生成と自動保守を実現していきたいです。また、UIエレメントにテスト専用のdata-testid属性を付与し、プロダクトコードを修正することでテストの安定化を目指します。