株式会社アクティブコアPublicationへの投稿
🆚

【E2E自動化】Autify, Playwrightと比較してmablを選んだ話

amama
に公開
E2E テスト
Playwright
mabl
Autify
tech

この記事は 株式会社アクティブコアのAdvent Calendar 2025 の 19日目の記事です。

今回は、私たちのチームでE2Eテスト自動化ツールの導入にあたり、mabl を選定した理由を残しておこうかと思います。

これから自動化を検討されている方の参考になれば幸いです。

1. E2Eテスト自動化ツール導入前の課題 😫

これまで私たちのプロジェクトでは、テスト自動化ツールを導入しておらず、リグレッションテストを含むすべてのテストを手動で行っていました。

しかし、プロダクトのフェーズ移行に伴い、以下の課題が顕在化してきました。

  • リグレッションテストの工数増大
    機能追加のたびに確認範囲が広がり、工数の都合上、手動テストだけでは全範囲をカバーすることが不可能な状態でした。
  • テスト範囲制限による欠陥の見逃し
    修正範囲を元にテスト範囲を決定してリグレッションテストを実施していたため、想定していない範囲でのエラーを見逃していました。

これらの課題を解決し、「継続的かつ安定した品質保証」 を実現するために、E2Eテスト自動化ツールの導入を決意しました。

2. 比較検討したツール 🛠️

選定にあたっては、以下の3つのツールを候補に挙げ、実際にPOC（概念実証）を実施しました。

  1. Autify (No-Code/Low-Code SaaS)
  2. mabl (No-Code/Low-Code SaaS)
  3. Playwright (Code-based OSS)

3. 選定の軸としたポイント 🧐

実は過去に自動化テスト導入に失敗した経験があるため、その反省を生かしつつ、今回は特に以下のポイントを重視しました。

  • 保守性: アプリケーションの変更に対するテストスクリプトの修正コストが低いこと。
  • 学習コスト: QAエンジニアだけでなく、非エンジニアのメンバーでも直感的に扱えること。

(余談ですが失敗した話はこちら)
過去の失敗談を記事にしています。よろしければ合わせてご覧ください。
https://zenn.dev/activecore/articles/96f7e0d9e7a037

4. 比較検討結果

今回比較検討した3つのツールの特徴をまとめました。
（※評価はチームのスキルセットやリソース状況に基づいた主観的なものです）

比較項目 mabl Autify Playwright
費用 △
(ややお高め)		 △
(ややお高め)		 ◎
(OSSのため無料)
学習コスト ◯
(ローコード)		 ◎
(直感的なUI)		 △
(要プログラミング)
保守性 ◎
(自己修復機能が強力)		 ◯
(AIによるメンテナンスあり)		 △
(コード修正が必要)
自由度 ◯
(条件分岐・JS挿入可)		 ◯
(JS挿入可)		 ◎
(コードで自在に記述可)
環境構築 ◎
(SaaSのため環境構築不要)		 ◎
(SaaSのため環境構築不要)		 △
(Node.js等の環境が必要)

🛠️ Playwright について

コードベースであるため自由度が非常に高く、エンジニア視点では魅力的でしたが、以下の点がネックとなりました。

  • コードベースのため一定の学習コストがかかること。また、コードを書くためのエンジニアリソースの継続的な確保が必要。
  • 環境構築やメンテナンスに一定の工数が割かれるため、「テストシナリオの設計」に集中するまでのハードルがやや高い。

🇯🇵 Autify について

UIが非常にわかりやすく、サポートも手厚い点が魅力でした。

  • ノーコードツールかつシンプルなUIで学習高ストはかからない印象。
  • 国内にサポートセンターがあり手厚いサポートを受けることができた。
  • if文による分岐など複雑なシナリオは作ることができない。(複雑な機能を排除し、誰にとっても使いやすいツールをコンセプトにしているとのこと)

非常に有力な候補でしたが、最終的な要件とのフィット感を詳細に比較した結果、今回は次項の理由によりmablを選択しました。

🏆 mabl について

最終的にmablを選んだ理由は、「ノーコードの手軽さ」 と 「高度なロジックへの対応力」 のバランスが最も優れていたからです。

  1. ローコードの手軽さ ✨
    mabl Trainer というChromeの拡張機能で自身の操作を記録することでテストシナリオを作成することができるため、使い始めてすぐの人でも1人でシナリオを作成することができます。

  2. 条件分岐やループ処理の強さ 🔄
    ローコードツールでありながら、条件分岐（if文相当）やデータの繰り返し利用などのフロー制御が直感的なUIで組みやすく、複雑な業務ロジックを持つ我々のアプリケーションに適していました。

  3. 自己修復機能（Auto-healing）の精度 🩹
    UIの変更（IDや属性の変化）を検知してテストを自動修正してくれる機能の精度が高く、テスト保守工数の大幅な削減が期待できました。

5. まとめ 🚀

ツール選定に「絶対解」はないと思います。

もしチームに非エンジニアが多く、シンプルな操作性を最優先するなら Autify がベストだったかもしれませんし、エンジニアが中心で整備をし、複雑なDOM操作や特殊な環境があるなら Playwright などのコードベースが適していたかもしれません。

今回は 「QAチームが、保守コストを下げつつ、ロジカルなテスト管理をしたい」 という文脈で mabl がハマった事例として紹介しました。
これからE2Eツールの選定を行う方の参考になれば幸いです。

株式会社アクティブコア
株式会社アクティブコアPublication

株式会社アクティブコアのテックブログです！日々の業務や個人開発で得た知見をエンジニアが発信していきます。

Discussion