テスト自動化ツールにMagicPodを選定した理由

はじめに

こんにちは。
第三者検証業務を実施している部門で、業務のDX化を担当しています。
今回、検証業務の対象システムや検証業務の効率化を目的として開発しているシステムのE2Eテストやリグレッションテストを自動化する目的で、テスト自動化ツールのMagicPodを導入しました。この記事では、数ある自動化ツールの選択肢からなぜMagicPodを選んだのか、その理由を紹介します。

テスト自動化ツールには以下のようなさまざまな選択肢があります。

• OSSのフレームワーク
  例: Selenium, Playwright, Cypress など
• インストール型ツール
• SaaS型ツール
  例: MagicPod, Autify, mabl など

OSSのフレームワークを選択しなかった理由

OSSのテストフレームワークには、SeleniumやPlaywright、Cypressなどがあります。これらのフレームワークはエンジニアリングの自由度が高いです。しかし、当部門は非エンジニアがメインのため、コーディングが必須のツールだとそもそも使われない、あるいは保守されないリスクが高いと判断しました。

エンジニアやコーディング経験のあるメンバーが部門に継続的に存在し、かつ十分な工数を割ける場合には、OSSフレームワークは有力な選択肢になります。しかし、当部門の状況では、メンテナンスの容易さや非エンジニアが扱えることが重要だったため、OSSフレームワークは今回の選定から外しました。特に第三者検証業務における自動化には、OSSのテストフレームワークは向いていないと判断しました。

インストール型ツールを選択しなかった理由

インストール型のテスト自動化ツールも検討しましたが、以下の理由から対象外としました。

1. 対応環境が制限されている
   一部のインストール型ツールは、macOSやLinuxに非対応であることもあるなど、試験環境が限られてしまう可能性がありました

2. スケーラビリティの制約
   利用人数が増えるにつれ、インストール型ツールではライセンス管理やインフラの対応が複雑になることが予想され、部門全体でのスケールを考慮すると適していないと判断しました

3. バグ対応や機能改善のスピード懸念
   SaaS型ツールに比べて、インストール型ツールはバグ修正や機能追加のスピードが遅れるイメージがありました。あくまでイメージなので、実際はそんなことはないかもしれません

SaaSツールの中でMagicPodを選択した理由

SaaS型のテスト自動化ツールには、MagicPod、Autify、mablなど、さまざまな選択肢が存在します。インストール型に比べ、スケーラビリティやメンテナンス性に優れている印象です。

その中でもMagicPodを選定した最大の理由は、イニシャルコストの低さです。自動テストの経験が乏しい部門において、まずは低コストで試してみたいというニーズに最適でした。自動テストの有効性を実証し、徐々に展開を拡大するフェーズでは、初期投資の低いツールが選びやすいです。

さらに、テスト実行回数に制限がない点や、同僚の利用経験者からのサポート体制が手厚いという評価も、安心材料の一つでした。

機能面については、基本的な部分では、どのSaaS型ツールも大きく変わらない印象を受けました。

MagicPodを導入してみて

実際に導入してみて、セットアップは非常に簡単で、操作性も直感的でした。定期実行や通知設定もすぐに行えました。

テスト作成時に、操作をトレースして自動でテストを作成してくれたら、より便利そうだなと感じました。

最後に

今回、さまざまなテスト自動化ツールを比較した結果、完璧なツールは存在しないと感じました。どのツールも何かしらの制限や制約があるので、組織の優先順位を決めて選定する必要があります。また、場合によっては複数のツールを組み合わせて利用することも有効な戦略となるかもしれません。