この記事について
新規プロダクトチームでQAチームの立ち上げとE2E自動テストの導入を行った（現在進行形）ので、その中でE2E自動テスト部分についてフォーカスした記事です。
体系的な内容ではなく、導入するにあたって検討したことや導入後の使い方、現状の課題感をメモとして綴っていきます。
想定読者
- E2E自動テストに興味がある人
- MagicPodに興味がある人
プロローグ
今現在携わっている開発チームはとあるかなり巨大なWEBサービスの一部のシステムのスマートフォン用のサブシステムをリプレイスしていくチームです。
そのチームでは既存システムの画面を少しずつ新規システムに段階リリースして移行していく開発を行っています。
一番最初のリリースで4画面ほどメインの画面をリリースした辺りからこの話は始まります。
私はエンジニアではあるもののこのチームにはPMO的なポジションで関わっていて、PMの手が回り切らない部分のサポートをメインで行っています。
とある日、PMから「リリースサイクルをもっと早くしたいのでリリースごとに発生するQAテストをもっと短くするために専門のQAチームとE2E自動テストの導入を行いたいんだけど、推進してほしい」というオーダーをいただきました。
QAについてエンジニアである私は専門性はないものの必要だしやってみたいと思ったので進めることにしました。
E2E自動テストの導入検討
色々端折って本来書きたかった、E2E自動テストの話をメインで書いていきます。
今回導入するにあたっていくつかツールの比較を行い、結果として2つのサービスをトライアル申込しました。
導入するにあたって前提条件
- エンジニアリングはできないQAさんがメインで使う
- フロントエンドは結構変更が頻繁に入る
- リリースは2週間に1回（もっと早めたい）
- 今後どんどんテスト対象は増えていく
つまり、開発と同じスピードで装着してなるべくメンテが発生せずに非エンジニアでも運用できることが求められている！！
ということで、以下をツールに求めました
ツールへの要望
- MUST
- GUIでテスト実装できる
- 変更に強い（≒オートヒーリング機能が付いている）
- WANT
- CIに組み込める or スケジュール実行可能
- seleniumを保守するエンジニアを1人月確保するより月額コストが安い
これらを満たすには有償のSaaSツールを使う以外に選択肢がなかったため、有償のもののみに絞って選定しました。
ツール（SaaS候補）選定
- Autify (https://autify.com/ja/ )
- MagicPod (https://magicpod.com/ )
- mabl (https://www.mabl.com/ja/ )
だいたい調べてもこの3つくらいだったので3つを候補にしました。
特に大きな理由はなかったのですが、社内の別組織で利用実績があることもあり、AutifyとMagicPodのトライアル申込をしてみることにしました。（今思えばmablさん勝手に候補から外してごめんなさい、、）
トライアルしてみて感想
Autify
-
できること・特徴
- 画面操作するだけで同様の操作のテストが作成できる
- 標準機能で実現できないテストはjs 記述で対応できる
- ツール上で、曜日・時間指定で任意のテストを自動実行できる
- スケジュール内の実行方法を 並列 / 直列 の選択ができる
-
できないこと・難点
- 画面操作で記録されたセレクタがどのような設定かは見られない
- 自動操作で記録されたセレクタを変更する場合、js 記述が必要
- 標準機能では、画面の操作・文言のチェックなど限られたテストしかできない
- 画面要素の検証には js の記述が必要になる見込み
- 条件分岐機能がないため、条件によって画面要素が変わる場合はそれぞれ個別のテスト作成が必要
- テストの共通モジュール化に制約があり、モジュール内に変数を使用できず、外からも渡せない。
- ex. ログインに異なるIdを使用するなら、それは１つのモジュールで共通化できない
- テスト作成・編集動線が分散しており、編集操作がややこしい
- ワークスペースをまたいだテストケースのコピー不可
MagicPod
-
できること・特徴
- 画面キャプチャから要素を選択してテストが作成できる
- デフォルトで設定されたセレクタを変更したり、セレクタに変数を組み込むことも可能
- 標準機能が充実しており、条件分岐・変数との一致確認など、要素検証や複数データセットに対応したテストが作成できる
- ツール上で、曜日・時間指定で任意のテストを自動実行できる
- テストの共通モジュール化した場合も、モジュール内外で変数をやりとり・使用できる
- テスト作成・編集動線が統一されている
- ワークスペースをまたいでのテストケースのコピー可能
- ワークスペースごとにユーザー権限設定可
-
できないこと・難点
- 標準機能にないテストの作成はできない
- スケジュール内の実行方法は直列実行のみ
- 実機テストは外部クラウドサービスとの連携が必要
まとめ
Autifyはjsを書いたり自由度が高い点はよかったが、今回は非エンジニアが運用する前提のため学習コスト的に難しかったです。それ以外の機能はそこまで大きな差はなかったですが、今回の要望的にMagicPodの方が合っているという判断をしました。
また具体的な情報なので記載していませんが、課金体系がAutifyはテスト実行回数上限拡張で課金、MagicPodはテストケース数の上限拡張で課金ということもあり、作成中になんどもテスト実行するので実行回数に制約がない方がよいなと思い、MagicPodを選択することにしました。
MagicPodに決めましたが、いきなりエンタプライズプランにはせずまずはスタンダードプランで開始してみました。月5万くらいなのでスモールスタートできてよかったです。（※なおAutifyはドル換算なので円安だと高くつきます、、ｗ）
MagicPodを導入することを決めてから決めたこと
ツールを決めたから「さあすぐに導入だ！」というわけにもいかないのでいくつか事前に決めておくことがあったのでこちらにも書いておこうと思います。
- MagicPodで担保する部分を決める（何が自動でなにが手動なのか）
- MagicPodを実行する環境を決める（本番、ステージング、開発、ローカルなど）
- テスト実行の頻度やトリガーを決める
- 開発フローへの組み込み方を決める
- MagicPod内で扱うデータパターン（csvファイルの管理方法を決める）
- 手動で準備が必要なところを洗い出す
- MagicPodのアカウント管理方法を決める
- セキュリティ脆弱性情報やリリース情報などのキャッチアップ方法を決める
- テスト結果の通知方法を決める
この辺りを事前に検討しました。すべてを完全に決め切ったわけではないですがある程度決めておくことでツールにお金を払ったらすぐに装着に取り掛かれるのでよいと思います。
MagicPodを使い始めての感想
Keep
- UIが分かりやすく非エンジニアでもすぐに使えるようになった
- リリース頻度が高くどんどん新しい機能がリリースされて便利になる（それでいて破壊的な変更は発生しない）
- 実際まだ一部装着しただけだが、スルーテストの工数を激減できている
- MagicPodのローカル用アプリケーションをインストールするとローカルから実行できる
- テストデータの登録もMagicPodで自動操作で登録できた（複数システムで構築されているサービスなので別チームのシステムからデータを設定する必要があるので）
- 開発者も動作確認用のデータ作成を毎回やるより一度MagicPodで実装してほしいデータを簡単に作れるようにできた
- 画像差分が出た場合に要確認と出てどこが差分だったのか画像同士を比較して確認できる
- MagicPod社への問い合わせ方法と対応がとてもスマートでよい
Problem
- ロケータをどうするかは少しだけエンジニアリング力が求められる
- 効率的にテストケースを装着しようとするとどうしてもプログラミング的な思考が必要になる
- 画像差分機能は便利だけど処理時間が長いので多用するとよくない
- Gitみたいにバージョン管理できない（履歴機能を駆使して頑張るしかない）
- MagicPod実装するためのテスト仕様書作成が必要（なくてもできるがなにもない状態だとなかなか実装のハードルが高い）
- 巨大なシステムの一部にだけ導入すると考慮することが多く難しい（E2E自動テスト自体の課題）
Try
- MagicPod実装観点でフロントエンドチームと実装方針について相談してみる（ここの値を取得できるようにカスタムデータ属性をつけてほしいとか）
- （まだないので）オートヒーリングでどこまで修復されるのか確認してみる
- IP制限の都合でまだクラウドブラウザから一括実行できていないので今後試してみたい