何度も挑戦し挫折してきたE2Eテスト、ついにSaaSのAI自動テストが福音となるか？！の巻
D.M.です。E2E テストのツール mabl について書きます。
TL;DR
・mabl はお手軽で素晴らしい。初期設定が簡単ですぐに開始できる。テスト作成とスケジュール設定が非常に簡単。修正もすぐにできる。
・さすがに Google reCAPTCHA は突破できない（できたらそれはそれでヤバい）。Webアプリ側で仕様上の特殊な処理を設けるしかなさげ。
・テストメール生成機能もあり非常に便利。（今回はうまく使えず。。）
・壊れたら自動でいい感じにしてくれる Auto Healing がすごい。逆に Auto Healing されたら困る、 NG にしたいケースでは Auto Healing をOFFにしたり、 Assert で正しい値が出ているかチェックするという逃げ道もある。また、 Auto Healing がうまくいかないときのチューニングは昔ながらの CSS や XPATH の Selector で HTML 要素を絞り込める。
目次
１．[問題提起] すぐに壊れるし、メンテされなかった E2E テスト
２．[設計編] そもそも E2E で何をテストするべきか
３．[実践編] ぼくのかんがえたさいきょうの E2E テスト
２．[設計編] そもそも E2E で何をテストするべきか
３．[実践編] ぼくのかんがえたさいきょうの E2E テスト
１．[問題提起] すぐに壊れるし、メンテされなかった E2E テスト
E2E テスト（End to End Test）はユーザが使っているのと同じように画面からシステムをテストをするという考え方です。自社でサービスを運営しているエンジニアとして、システムの E2E テストがプログラムで自動的にできている状態は一つの目指す理想形と思っています。
この実現ために過去にさまざまなテストを実装してきました。
しかし、例えば Selenium と聞くとみんな暗い顔をします。やりたいテストは一応実装したことはあるんだけど、結局どの UI の自動テストも非常によく壊れる。本当によく壊れるので累積で初回の開発コストの何倍もメンテ時間がかかったりします。他のタスクの兼ね合いもありメンテが後回しになりがち。初期設定まわりも結構めんどくさく簡単に修正を手伝ったりすることもできません。
Selenium が悪いというよりか Web のシステムと E2E テストとは相性が悪すぎるのが問題です。そもそも Web のシステムは変化が激しすぎる。 Selenium の後継というべきブラウザ操作系の OSS は最近では Playwright や Puppeteer がありますが、結局すぐに壊れるプログラムをもう1回始めから書こうという気になれないのが本音でした。
そこに最近現れたのが、新しい AI を用いた自動テストサービスです。軽く調べた感じ海外のもので mabl （メイブル）、日本のもので Magic Pod, Autify などがありましたので、今回は mabl のトライアルを使った感想を書いてみようと思います。
２．[設計編] そもそも E2E で何をテストするべきか
E2E テストはとにかく壊れまくる、時間がかかるという2つの重大な弱点を抱えています。そのためやたらめったら作るというより、どこをテストするべきかというターゲットの絞り方が非常に重要になってきます。
まずは設計思想からおさらいしていきます。
いろいろと調査した結果、以下の4点に落ち着きました。
・E2Eテストでは、ユーザがこうやって使うよっていう普通の利用フローをテストする。
・ここが壊れていたらサービス上や収益上の理由でやばいというところをテストする。
・時間がかかる。なのでシンプルにする。（境界値テストなど単体テストでやるべき内容は含めない）
・壊れやすい。なので誰でも直せる状態が好ましい。
今回対象となるサービスとして GMO ID と GMO ポイントに導入してみようと思います。
GMO ID
https://id.gmo.jp/
GMOポイント
https://point.gmo.jp/
私はこのサービスの開発に5年以上関わっており、このサービス自体が15年以上続いていて、何度もレガシーのリニューアルを行ってきました。 E2E テストも何度かトライしているのですが、様々な理由でうまくいっていません。
もうちょっと議論を深めるため、本番環境での実施に的を絞って考えていこうと思います。
サービスにとって本当に重要な箇所だけを E2E テストする
GMO ID ／ GMO ポイントは、 GMO インターネットグループ全体で利用されるログイン基盤システムであり、いくつかの点で特に E2E テストの対象にできたらいいなと思っているのは以下の機能群です。
１．ログイン系テスト
ログインができないとサービスとして根幹が動いていないことになりますので非常に重要度が高いです。グループ会社も多くが連携・依存しているシステムなので影響は計り知れません。ぜひともE2Eテストを実施しすぐにでもエラー検知をしたい部分です。
２．新規登録系テスト
こちらもログインと同様の理由でやりたいのですが、問題が多々あります。まず E2E テストを実施すると本番で無駄なアカウントを大量に作ってしまいます。登録数はビジネス的な KPI にもなるため微々たる量とはいえ意図的に増やしてしまうのはちょっとおかしいという議論があり、また、仕様上、テストごとに新規メアドを生成して登録する必要があるので結構手間です。パッと思いつく方法としてテスト用メールを生成してからすぐに退会するなどがあるのですが、現状の仕様ではあちこちにゴミデータが貯まってしまうため却下となっています。テスト用に特殊な処理を組んでしまうとそもそもの E2E テストの意図であるユーザが普通に使うという部分から外れてしまうので変な作り込みも避けてきました。
結論として、現状では新規登録系のE2Eテストはやらない方針になりました。実際登録部分だけが壊れるケースは稀（例えばDBが特定のテーブルへのディスクへ書き込みができないような場合が該当）なので、別の監視等で担保するということにしました。
３．課金系テスト
GMO ID と GMO ポイントは決済も持っていますがここも E2E テスト導入が非常に困難です。
グループ会社のサービスであるGMOメイクショップ、カラーミーbyGMOぺパボ、くまポンbyGMOとも連携していますが、こちらを対象にしてしまうと物理的な商品をテストで買う必要があり、テストデータの用意などがちょっと大掛かりになります。ゲソてんbyGMOにてゲーム内通貨ゲソコインを買う部分もありますが、クレジットカード決済が発生するのであとあとで解除する部分の手運用が必要になり、他にも中間コストが発生するので本番ではやらない方向になっています。別の監視系でカバーする方針で考えています。
３－２．ポイント発行系機能
GMO ポイントはグループ会社に API でポイント発行機能を提供しています。ポイント自体は会計監査の対象にもなるため不具合が一切許されず、テスト用に適当に発行するということが本番では不可能です。加えて、テスト用に変な機能を作ると不正のリスクが怖いです。GMO あおぞらネット銀行との連携部分ではポイントと現金の交換機能があります。ただ下手にテスト用で無限にポイント交換をする機能を作ってしまうと間違いなく監査で怒られます。
テストとしてユーザのポイント残高取得 API が対象にできそうですが、根本的には DB への Select で成り立っており、最低限どこかページでデータの登録変更削除をテストしておけば事が足りそうです。
４．メール系機能
メールが届かないんだけどというお問い合わせは結構来ます。だいたい何らかの原因で迷惑メールに振り分けられたりしているのですが、稀にメール送信のシステムが高負荷で遅延していたり、メールが文字化けしていたりいろんな不具合が発生します。新規登録時に確認メールを送っていることもあり、ここは可能であれば E2E テストに組み込んでおきたい点です。
５．ミドルウェアのデータストア接続部分
DB と ElasticSearch と Redis がミドルウェアのデータストアとして動いており、どれもサービス運営上クリティカルな役割を果たしています。
複数の箇所で監視があるのですが、 E2E テストもできていれば非常に心強いため、ここも対象にしていこうと思います。
ということでログイン系、メール系、ミドルウェア接続系が対象にできそういう結論になりました。
３．[実践編] ぼくのかんがえたさいきょうの E2E テスト
さてここから mabl を使っていきます。日本の公式ページ
https://www.mabl.com/japan
mabl は E2E テストのプラットフォームを提供している SaaS です。
今回これを選んだ理由に、テストの壊れた箇所を AI が自動的に修正してくれる Auto Healing というとんでもない機能があります。これを使い倒していくぞ！というのが今回の最大の意図です。
いざ利用開始
トライアルができたのでアカウントを作成して利用してみました。クライアントアプリをダウンロードするとすぐに使い始めることができます。
クライアントアプリのメニューを見ると中でエンジンとして動いている OSS が Playwright と Puppeteer でであることがわかります（下の画像参照）。これでブラウザをプログラム操作するスクリプトを生成してうごかしているのだなと推測できます。
1点注意なのが上記の画像にもある Extensions enabled を ON にする必要があることです。これをやっておかないとテスト作成時にエラー「 Could not start training session: Error: Unable to start Chrome session 」が出て一切使うことができません。こんなイージーなことに気がつかず1日無駄にしてしまいました（泣）。公式さんこれは FAQ かなんかにあげておいてください～
具体的なテスト内容
上で検討した4点を検証対象にしてみました。今回やりたいこと
１．最重要機能であるログインの E2E テスト
２．マイページで DB の CRUD を一通り流す
３．メールアドレスを変更して mabl mailbox を試す
４．ショッピング商品検索で Auto Healing を検証する
１．最重要機能であるログインの E2E テスト
まず作成方法ですが、以下の流れです。１．mabl の管理画面のメニューから Tests を選び新規作成開始
２．テスト名やドメインなど初期設定を登録
３．テスト対象のサービスのログイン画面を開き、IDとパスワードを入れる操作をする
４．完了！
mabl はブラウザ操作をダイレクトに記録することができるため普通に自分のアカウントでログインすると即座にスクリプトが作成されます。 mabl 管理画面での前後の登録部分を含めてもログインのテストがものの5分で完了しました。これは早い。
1回1回の実行は詳細まで画像付きで記録されています。
このテストをひとまず試しに1時間15分に1回実行するというスケジュールにしてみました。以下のように実行履歴が一覧表示され、実行時間等も計測されています。
Google reCAPTCHA 問題
ここで当然の話なのですが、大量のボットによるログインの高負荷やリスト型攻撃のようなセキュリティ攻撃を防ぐためにログイン画面には Google reCAPTCHA が入っています。で、案の定、mabl の E2E テストのアクセスがボットと判定されてしまいました。
これでは全然テストができないじゃないかと思ったのですが、 mabl 自身も当然ながらこの問題を重要視しており、検証用の画面でテストを行い、公式ブログで解説しています。
Testing reCAPTCHA sites with mabl
https://www.mabl.com/blog/testing-recaptcha-sites-with-mabl
結論としては v3 はやっぱりボットでは突破が難しいようです。 Google もいい仕事をしてくれています。
Google reCAPTCHA 対策
これに対して E2E テストが正常に行えるようにする対策としては、どういう選択肢があるでしょうか？答えはシンプルに、Webアプリケーションの仕様でゴリゴリ対応することです。
v3 は仕様上 Google がそのアクセスをボットかどうかを示す値を返してくれるため、その後にあのパズル画面を出すかどうかはアプリケーション側で実装するようになっています。実装として特定のIPまたはアカウントによるログインの場合はボット判定をせずに常にログインが成功するようにしてしまえばこの問題は解消できるわけです。
２．マイページで DB の CRUD を一通り流す
DB で Select, Update, Insert, Delete が一通り実行されるようなシナリオを組んでおきたいと思い、マイページの送付先情報というページでやってみることにしました。これは商品購入時などで利用する送付先の住所を事前に登録しておく機能で、1ユーザあたり複数の住所が登録できます。
単純な CRUD 処理で画面もシンプルであったため15分ぐらいで E2E テストを作ることができました。
1か所ハマった点としては、セレクトボックスの選択です。どういうわけか HTML の option タグの value 値の指定では選択されなかったので、表示 text の値で一致するものを選択する実装にしました。 mabl ではこの辺の HTML 要素を判定するロジックで、 Selector の修正が直感的にすぐに変更できたのは大変使いやすいと思いました。
また point.gmo.jp と id.gmo.jp の2つのサイトをまたぐようなテストも特に細かい設定なく実装できました。その辺りも柔軟で良いなと思っています。
３．メールアドレスを変更して mabl mailbox を試す
マイページでは現在利用しているメールアドレスの変更ができますので、これをE2Eテストの対象にしてみます。マイページで変更するメールアドレスを登録したあとに確認メールが飛びます。その文面内にある確認リンクをクリックする必要があります。
以下の確認メールが届きます。
で、結論としてはこれは失敗に終わりました。
mabl mailbox
mabl は mabl mailbon という非常に便利なメール機能を提供しており（エンタープライズ用だがトライアルでも利用可）、テスト用メールを即時発行して使うことができます。おかげで毎回自分で使い捨てのアドレスを生成する必要がありません。テストを自動化する上で、メールアドレスの用意が一番めんどくさかったりするのでこれは大変助かる機能です。いざテストを実行してみると、専用変数で指定した箇所でランダムなメールアドレスを生成し、受信ボックスまで提供してくれます。即座に届いたメールの内容も Assert 機能で正しいかどうかを判定することができます。
届いたメールを開けてみると。。
完全に文字化けしてしまいました（泣）
これは mabl mailbox が UTF-8 に対応しているのですが、なんと GMO ID のメールは SJIS です（大泣）。mabl の問題というよりかこちらの問題になります。ホント恥ずかしいのですが、いろいろな都合で古い仕様が残ってしまっていることが問題になる一例ではないでしょうか。。
またこのメールボックスの機能では文面内のリンクを押すということができなかったため、結局このテストは中途半端に終わりました。
別のサイトのメーラでテストしてみる
ちなみにですが、いわゆる Web ブラウザでメーラを提供しているタイプのメールサービスなら正常に受信できるところがありました。もちろんリンクもクリック可能でした。この場合にハマった点としては、メールの文面内の確認リンクが毎回微妙に変わる点です。リンクはこのような形をしています。
この URL のパラメータにワンタイムトークン ott が毎回変わる仕様になっています。
はじめて mabl でこのシナリオを実行したとき、この ott の変更に全く対応できず、要素が見つかりませんエラーを出し続けていました。
ここでいよいよ Auto Healing が効くのか？！と思って何度か実行してみましたがあまりいい結果にならなかったので、手動チューニングして Selector の部分一致を適用しました。
以下のように「 contains 」で「…ott= 」 として先頭部分だけを一致させています。（ = の後ろのパラメータ部分を検証対象としていません）
結果的にこの変更で非常に安定するようになりました。無理に AI に任せず、人間がルールベースで記述できる部分は明示的なルールを設定したほうが確実になる事例かと思います。
また Gmail を利用したテストを試みましたが、Google へのログイン自体もプログラムにより自動操作されたブラウザでは拒否するようにチェックが入っているようでした。（たぶん RPA を使えばいけると思う）
そしてよく調べたらこれは Google の規約違反のようなのでそもそもやめることにしました。自分のサイト以外をボットで利用するのは本当に気をつけないといけないです。
４．ショッピング商品検索で Auto Healing を検証する
目玉機能である Auto Healing を試そうと思いましたが、頻繁に変更が入る部分を自分のサービス内で見つけるのが意外と苦労しました。数日考えて気がついたのがショッピングの商品検索画面（GMOポイントモール）です。このショッピング画面用のデータはグループ会社から定時バッチで連携して受けて取っています。したがって新着商品にはちょこちょこ変更が入るという仕様です。ちょうど Auto Healing の実力が確認できそうだと思いませんか？！？https://point.gmo.jp/shopping/top
結論としては Auto Healing の効果がすぐに確認できました！
15分に1回ぐらいショッピング検索画面を巡回する E2E テストを動かしてみましたが、商品が入れ替わってチェック対象の商品名が変更された後でもすぐに Auto Healing が効いてテストを続行してくれました。これはありがたい！
テスト作成時、 HTML 要素の Selector に商品名の text 部分を指定する実装をしていましたが（わざと変更されやすいところをテスト対象に組み込んでみた）、このレベルの画面の更新はぜんぜん気にしないでテストを進行してくれています。（上の画像では、テストスクリプトには対象文言として「餃子」を指定しているが、実際の画面の文言は「COCO壱番屋」になっているのに、テスト成功と判定されている）
逆にテスト時に厳密にこの文言が出てないと困るというケースもあると思います。これは Assert 機能で厳密文言チェックを実装できるので心配無用です。また Auto Healing を効かせたくないところは OFF にしたりもできるようです。
できなかったところ
画面でコピーしたものをペーストする操作はちょっと難があるようです。
mabl の中で動いている Playwright のほうをちょっと調べてみましたが、貼り付け機能は見つかりませんでした。
そもそも JS が勝手にクリップボードを操作するのはセキュリティ上問題があるため、例えば Chrome では settings で JS によるクリップボード操作の許可を ON にしておく必要があります（または画面でダイアログで許可をする）。 mabl の場合、ブラウザは毎回まっさらに初期化されてから実行が始まるため（そもそも人間がいない前提で動かすのでダイアログの許可を押すわけにもいかず）、この辺を変更するのは簡単ではなさそうでした。
回避策などもうちょっと調べてみようと思います。
まとめ
・mabl めっちゃ簡単。操作するだけでもうテストが作成できてしまう。テストを作っているのが楽しくなる。
・Google reCAPTCHA は突破できないのでアプリケーション側で仕様上の考慮が必要。
・mabl mailbox 便利だが sjis に未対応。
・Auto Healing は強力。メンテコスト激減。仮に Auto Healing が効かなくても CSS XPath の Selector で HTML 要素は特定できることが多い。
