なぜSeleniumを選ばなかったのか～AutifyとMagicPodを選びました～

こんにちは。QA Engineerの@testtattoです。
今回はE2Eテストの自動化にあたって、どういった考えでツール選定を行ったのかを話したいと思います。

対象読者

以下に興味や関心を持つ方を対象読者として想定しています。

E2Eテスト自動化によって課題を解決したいが、どういった技術があるのか分からなくて困っている人
E2Eテストの自動化は実現できているが、継続に課題を抱えている人
テスト自動化なら何でも興味がある人

まえがき

読んでもらう前にいくつかの前提を共有します。

リリースサイクルについて

当社のwebプラットフォームのリリースサイクルは一部のマイクロサービスを除いて基本的には週次です。決まった曜日で各プロダクトのプルリクエストを取り込んで、リグレッションテストを実施し、リリースブロッカーがなければリリースしています。

流れとしてはこんな感じです。

月	火	水	木	金
特になし	リリース用のrelease-branchをきってstaging環境をdeployする	staging環境で手動のリグレッションテストを実行する	手動のリグレッションテストが終わり次第、本番にdeployする	本番で何かあったときの対応

手動のリグレッションテストはテストベンダーに依頼して実施していだいています。また、リグレッションテストではクロスブラウザ(IE, Chrome, Safari, スマホブラウザ)テストも含んでいます。

課題

我々が課題に感じているのは、上記のリリースサイクルの中で手動リグレッションテストの実行が1日半程度かかっており、今後リリースサイクルを早める際のボトルネックになるということでした。

また、プロダクトが拡大していってリグレッションテストのボリュームが大きくなった際のコスト面も気になる要素でした。

解決方法の方針決め

E2Eテスト自動化以外の方法も検討しました。簡単な検討結果も併せて記載します。

コストをかけてテストベンダーの実施している人数を増やしてもらう
- 年毎にコストが1.5倍に増えている状態だったので、さらなるコスト増加は許容できない
クロスブラウザの対象を減らす
- 不具合分析結果から対象ブラウザを減らした。時間短縮、コスト減少には繋がったが高速リリースはできない
リグレッションテストのテスト項目を減らす
- 精査をしてみて、減らせる部分はあったがそこまで不要なケースはなかった
別のテストレベル(Unit test, Integration test)で品質を担保する
- 不具合分析結果からブラウザ依存の不具合が多かったので、このテストレベルで担保できない

などです。結局、E2Eテスト自動化が一番効果的であろうという結論になりました。

ツール導入までの主な流れ

進め方は以下のような流れで行いました。

組織全体で課題感の認識は揃っていたこともあり、E2E自動テストツールを導入するということへの反発はなかったです。

噂では、ビジネス側や開発者が非協力的で中々進まないという事例もあるらしいので、自分は恵まれていました。

E2Eテスト自動化の目的、実現したいこと

ツールに対しての要件を整理するために、E2Eテスト自動化の目的と実現したい"世界"の明確化をしました。

最優先(MUST)
- 高速リリースサイクル(日次)が実現できる
- リリースサイクルとは独立してリグレッションテストを実行できる
なるべく実現したい
- 手動のリグレッションテストのコスト削減
できると嬉しい
- ビジネス側の人でもテストに関われる

コストカットよりも柔軟なリグレッションテストの実施ができて、プロダクトの価値を早くユーザーに届けられる状態になっていることに重きを置きました。

ツールに対しての要件・制約

実現したいことのために必要な要件や制約を導出しました。

1. CI/CDに組み込める
2. IE対応
3. Native Appもできる
4. 開発環境の認証を回避できる(セキュリティ要件をカバーした上で)
5. メンテナンスコストが低い
6. 開発者も取り組めるように学習コストが低いものが好ましい(将来的にはビジネス側も)

簡単に1つずつ説明すると、

CI/CDに組み込める
リリースサイクルに組み込みたいので、当然の要件になりますが、組み込めないツールの方が珍しいのでそこまで気にしなかったです。
IE対応
当時はIEがサポート対象ブラウザに入っており、かつ、ブラウザ依存の不具合が多かったので外せない要件でした。(今は対象外)
Native Appもできる
スタディサプリはwebとNative App両方でサービスを提供をしているので、統一的に利用できるものが良いと考えていました。
開発環境の認証を回避できる
SaaSのクラウドプラットフォームからテストしたい環境にアクセスした際にセキュリティ上そのままでは外部からの不正アクセスとして弾かれます。なので、セキュリティを損なわずに開発環境へアクセスできることが必要でした。
メンテナンスコストが低い
当時は自分1人だったので、変更に強い、Flakyになりにくい、インフラ面で手間がかからない、といったところも重視していました。
開発者も取り組めるように学習コストが低いものが好ましい
QAエンジニアだけが自動テストを作成していくというよりは、オーナーシップは持ちつつも、チーム全体で柔軟に運用できることを考えていました。

ツール調査

初期候補としては以下です。

Selenium webDriver + appium

メリット
- デファクトスタンダードであり情報豊富
- 複数言語対応で開発者が新規言語を覚えなくてすむ
- マルチブラウザ対応可能
- I/O処理もスクリプトに組み込める
- コードなので、git管理ができる
デメリット
- ロケータの管理が面倒
- カスタムデータ属性やidがきちんとfrontendにないとflakyになりやすい + メンテコストでかい
- 環境構築とアプデ追従が厄介

Cypress

メリット
- 開発者の一部はすでに使っていて、なじみがある
- 情報豊富
- 実行速度がSeleniumより速い
- コードなので、git管理ができる
- I/O処理もスクリプトに組み込める
デメリット
- IE非対応
- 言語がJavaScriptに限定される
- Native Appに対してのテストには使えない

Autify

メリット
- レコーディングによってただ画面内操作をするだけでテストが作成できる(学習コストが安い)
- self-healingによって軽い要素変更ならメンテ不要で追従できる(メンテコスト安)
- メールテストが容易
- サポートがしっかりしている
- native(iOSのみ)も対応できる(検討時にサービス開始した。現在はAndroidも対応)
- 企業ごとの固定IPが振られるので、セキュリティを満たしながら開発環境へアクセスできる
デメリット
- 実行回数による従量課金制
- 同じ手順を別のテストケースで共有化できるが、冒頭でしか呼び出せない(現在は途中でも呼び出せるが、JSステップがその中では使えないといった制約がある)
- SaaSなので、提供している機能に限界がある
- 有償サービスなのでお金がかかる

MagicPod

メリット
- assertが豊富
- 手順の共有化ができ、どこでも呼び出せて、変数も渡すことができる
- ロケータを自分で調べる必要がなく、作成がSeleniumに比べてかなり楽
- webとAndroidの実行速度はGUI操作系の中ではかなり速い
- webとNative App(iOS, Android)どちらも対応している
- サポートがしっかりしている
- 実行回数による課金なし(並列度のみ)
- AIによる自動修復機能があり、メンテナンスが容易
デメリット
- SaaSなので、提供している機能に限界がある
- 学習コストはAutifyと比べると高い(要素特定に最低限のHTML知識が必要になることが多い)
- マルチブラウザ対応するにはデバイスファーム(SourceLabs、Remotekitなど)の連携が必要
- 選定初期時は固定IP割り振りがなく、セキュリティ的に問題があった(その後の機能追加で解消された)

Mabl

メリット
- Postmanと連携して、APIテストも合わせて簡単にできる
- Auto-healing機能により要素の自動修復がされ、メンテナンスが容易
デメリット
- Native Appの対応なし
- IEも確か非対応

webのみだったこともあり、トライアル申し込み前に選定から外しました。

調査後の結論

Selenium, Cypressは拡張性やコード資産の面では優れていると感じましたが、どうしてもメンテナンス面のコストが割に合わないと感じました。

現状、今のプロダクトのFrontendはカスタムデータ属性はないですし、クラス名を自動生成していたりで、要素特定に優しくないという背景もありました。開発者と協力してE2E自動テストがやりやすいようにしていくというのもアプローチとしては良いと思うのですが、不確実性が高くなってしまうのは避けられないです。

QAエンジニアのメンバーが十分にいて、「E2E自動テストはQAエンジニアが全て面倒みます！」という組織であれば、このメンテナンスコストは許容なレベルかもしれません。

そういった理由から自動修復機能があるSaaSから選ぶことにしました。そう、AutifyとMagicPodです。

初期コストとランニングコストの見積

ここは社内の予算の話になるので、ちょっと薄めに話します。

まずはAutifyから契約とコスト周りについて相談させていただきました。要件的にエンタープライズプランの一択で、月々のコストは手動テストから考えるとかなり安かったです。

ただし、手動テストよりは作成の人的コストや壊れないように日々メンテナンスしていくコストもあるのでそこだけ比較するのは良くないですが、それを加味してもコストメリットも出そうだという肌感がありました。

MagicPodは当時はセキュリティ要件を満たせなかったので、機能実装されてから連絡をもらい、契約にいたりました。こちらについても同様に十分にコストメリットが出ると判断しました。

パイロットプロジェクトでフィジビリティスタディ

ここのパイロットプロジェクト選びはかなり重要です。大きすぎると途中で頓挫することが見えていたので、マイクロサービスとして切り出されているプロダクトを対象にしました。

その話については以前@pankonaさんが記事にしているので、こちらをご覧ください。

Autify を導入したらなかなか良かった話

このチームではAutifyでE2Eテスト自動化を実現しました。自分が主に携わっているスタディサプリ中学講座のプロダクトチームではMagicPodでE2Eテスト自動化を実現したので、これは別の機会に紹介したいと思います。

AutifyとMagicPodについて

機能の差異はありますが、どちらも大抵のE2Eテスト自動化が実現できる素晴らしいサービスです。迷っている方がいればすぐトライアルを申し込んでみましょう。

トライアル中でもサポートが非常に手厚いので、ツールの使い方がわからなくて手詰まりになるようなこともないです。

ちょっと脱線しますが、当社ではプロダクトやチームによってAutifyとMagicPodの使い分けを現状はしていますが、基本的にはどちらか一方に絞ることをおすすめします。相互にテストケースの互換性とかないですし、学習コストも増えるので。

終わりに

ツール決定までの一連の流れを紹介させていただきました。もし、これからE2Eテスト自動化を実現したいと考えている方の参考になれば幸いです。

ツールを使ったノウハウ的な話は今回はしていないので、こちらも別の機会に記事にできればと思います。

私達のチームでは、一緒に最高のプロダクトを作っていってくれる仲間を募集しています！
少しでもご興味がある方はこちらのページからご連絡ください！

スタディサプリ Product Team Blog

株式会社リクルートが開発するスタディサプリのプロダクトチームのブログです