ノーコードE2Eテストツール「mabl」を試してみた
こんにちは。今回は、GUIベースでE2Eテストが作成できるSaaSツール 「mabl」 をトライアル利用してみたので、その所感をまとめます。
導入の背景
弊社で開発しているファンメディアプラットフォーム 「Bitfan」 では、アーティストやタレントがファンクラブを運営できるダッシュボード(管理画面)と、それを閲覧・利用するエンドユーザー向けの公開画面の両方を提供しています。
このようなサービス構造上、フォームや表示状態の組み合わせが非常に多く、例えば:
- チケット販売連携の有無
- 公開/非公開設定の切り替え
- 入力内容による動的表示の変化
といった要素が複雑に絡み合い、UIの状態数が爆発しがちです。
そのため、人力のモンキーテストでは網羅的な検証が困難になっており、自動化の必要性を強く感じていました。
そこで今回、GUI操作で比較的簡単にE2Eテストが作れると噂のmablを試してみることにしました。
実際にやってみたこと
今回は、チーム内で整理されていた「記事投稿・編集」に関するリグレッションテスト観点をもとに、実際にmablで同じ内容のテストシナリオを作成してみました。
さらに、ログイン動作の確認も作成してみました。
結果として、作成には約2時間かかりましたが、その後はボタン一つで何度でも実行できる状態になり、大きな効率化につながりました。
良かった点
✅ AIによるアサーションが強力
要素指定だけでなく、「画面全体が正しく表示されているか?」をAIが判定してくれるのが便利でした。
たとえば「フォームのページにおいて 表示が正常に行われているか」という確認内容に対し「input要素があるかどうか」のような単一判定に加えて、画面全体の判定(表示されるべきフォームパーツが適切な位置に配置されているか 不自然な表示がされていないか)異常時の見落としをAIが補完してくれるような安心感があります。
✅ レポートが見やすい
テストごとの 実行時間・成功率・スクリーンショット付きの結果一覧 が非常に見やすく、UI変更の影響範囲も把握しやすいです。
また、実行時間の推移を確認することで、ページ表示速度などのパフォーマンス変化もなんとなく見えてくるのは地味に嬉しいポイントでした。
✅ チーム共有に強い
GUIベースなので、mablをインストールするだけで誰でもテスト実行が可能。
エンジニアだけでなく、ディレクターや非エンジニアの方でも、再現テストをmablで作ってもらい、それをエンジニアが実行して確認する——そんな運用の可能性も感じられました。
気になった点・課題
-
トレーナー画面と実行画面のサイズ差による挙動の違い
UIサイズが異なることで、クリック位置や検出対象がズレる場合があり、ここはやや注意が必要です。 -
GUI操作が煩雑になることがある
同じ操作を複数回繰り返すようなテストでは、GUIでの作業に手間がかかることがありました。
コードで書けば一瞬なのに…と思う場面も。
他ツールとの比較所感
CypressやPlaywrightと比べて、以下の点でmablに魅力を感じました:
- レポートの可視性が高く、パフォーマンス傾向も把握しやすい
- セットアップが非常に簡単で、幅広い職種にとって導入しやすい
- GUIベースで、共有や再現の手段としてチーム内に浸透しやすい
今後の導入可能性
導入の可能性は十分にあると感じています。価格次第ではありますが、今後さらに調査を進めていく予定です。
また、他のGUI系E2Eツール(例:Testim、Functionizeなど)との比較検証も視野に入れています。
まとめ
mablは、GUIベースのツールとしては想像以上に実用的であり、「非エンジニアも使える自動テスト」 という観点で非常に魅力的なツールでした。
属人的なUIチェックの負荷を軽減し、再現性のあるテストをチーム全体で持つことができる、そんな体制づくりに一歩踏み出せた気がします。

株式会社SKIYAKIのテックブログです。ファンクラブプラットフォームBitfanの開発・運用にまつわる知見や調べたことなどを発信します。主な技術スタックは Ruby on Rails / React / AWS / Swift / Kotlin などです。 recruit.skiyaki.com/
Discussion