非エンジニアでも自動テストが作れる、MagicPodを使ってみた

開発チームが拡大し、機能が増えるにつれて、品質管理の重要性が高まってきました。特に主要機能以外の部分で想定外の動作が発生することがあり、これらを効率的に検出する仕組みが必要になってきました。

今回、非エンジニアでも使える自動テストツール「MagicPod」を実際に使ってみましたので、その体験をご紹介します。自社サービス「トコトン」でのテスト実施を通して感じた、MagicPodの特徴や使用感をまとめました。

執筆時点で提供されている機能で、MagicPod側で機能が変更になる場合もあります。

MagicPodとは

MagicPodは、プログラミング知識がなくても直感的にWebアプリケーションの自動テストを作成できるクラウドサービスです。

MagicPod公式サイト

主な特徴

• ノーコードでのテスト作成：ブラウザ上の操作を録画するような感覚でテストシナリオを作成
• AIによる要素認識：画面要素を自動で認識し、レイアウト変更にも対応
• 多様なブラウザ対応：Chrome、Firefox、Safari、Edge等での動作確認が可能
• 継続的インテグレーション対応：CI/CDパイプラインとの連携も可能

トコトンのテストでMagicPodを使ってみた

背景：なぜ自動テストが必要になったのか

自社で開発・運営している「トコトン」では、以下のような課題が顕在化していました。

機能拡張に伴う複雑化

• 新機能の追加により、既存機能への影響範囲が見えにくくなった
• 開発に関わるメンバーが増え、全体像の把握が困難になった

テスト漏れの発生

• 主要機能以外の部分で想定外の動きが発生することがあった
• 特に初期設定部分など、普段あまり触らない機能の壊れに気づけなかった

効率性の課題

• 手動でのテストは時間がかかり、部分改修の度に全機能を網羅的にチェックするのは現実的ではなかった

これらの課題を解決するため、自動化による効率的なテスト実施を検討し、MagicPodの導入を決めました。

なお、最終的に決めたのは、自社で他のプロダクトのテストにMagicPodを使っていたからです。
他のツールを入れるよりコスト面でも操作面でも、そして社内での手続き面でも既存ツールを活用するのが一番良いと判断しました。

使用感：実際に使ってみて感じたこと

RPAツールのような直感的な操作感

過去にブラウザの操作を自動化するRPAツールを使った経験があったため、MagicPodは迷いなく使うことができました。

操作の流れ

1. バーチャルブラウザでテスト対象のページにアクセス
2. 実際の操作手順をMagicPodでなぞる
3. 期待する結果（アサーション）を設定
4. テストを実行して結果を確認

この一連の流れが非常にスムーズで、プログラミング経験がそれほどなくても直感的に理解できる設計になっていると思います。（HTMLの構成ぐらいは知っておかないとさすがに難しいかも）

開発効率を重視した使い方が最適

実際に使ってみて分かったのは、MagicPodは「細かくいろんなケースを作る」よりも「通常パターンが問題ないかを確認する」用途に向いているということです。

理由

• 開発は単純に手数がかかるため、複雑なテストケースを大量に作るのは現実的ではない
• 主要な機能が正常に動作することを継続的に確認することで、大きな問題を早期発見できる
• エッジケースよりも、ユーザーが最も使う機能の安定性を担保することが重要

変数機能の便利さ

MagicPodの変数機能は便利でした。
日付をキーにしたものが多かったので、今日の何日後を選ぶ、という可変の要素もどうにか実装出来ました。

要素設定は少し面倒

要素識別の問題
自動で設定される要素のIDが「id=input-xxx」のような通し番号になってしまうことがよくあります。

これらの連番は変更される可能性が高く、テストが不安定になるリスクがあると感じ、xpathなどの固定要素に変更する手間がありました。
この作業は少し面倒でしたが、基本がこれってことは実は変えなくてもよかったのかも？と後で思ったり。どうなんだろう。

今後

AIの活用とか、Gitとの連携とかいろいろできるみたいなので試してみたい。

まとめ

非エンジニアでも自動テストを導入できる点は非常に価値が高く、開発側に負担をかけることなくテストの自動化を実現できました。

これさえあれば通常のテストは不要！とはまだ言えませんが、確認漏れを減らすことにはつながっていると思います。

今後も継続的にテストケースを充実させ、より安定したサービス提供を目指していきます。