MagicPod導入から半年、オープンロジQAチームで実際にやったこと
オープンロジのQAチームでは2025年の2月にE2Eテスト自動化ツールとしてMagicPodを導入しました。オープンロジでは2018年からテスト自動化に取り組んでいましたが、2021年に1度目のツールの再選定を行い、Ghost Inspector（以下GI）を4年ほど利用してきました。本記事ではMagicPodの導入前後で何を行ってきたか、どう変わったかについてご紹介します。
ツール選定〜導入
ツール選定前にまず2E自動テストの全体像を把握するため、課題出しを行いました。課題出しの内容は以下のnoteにまとめています。
見つかった課題を早期に解決できるツールをリストアップしました。29のツールを一覧化しましたが、「ノーコード」と機能、価格帯で絞り込み最終的に見積もりまで行ったのは以下5つのツールです。見積もり兼サービス説明ではツールベンダーの担当の方からの操作方法等の説明の他、実ユーザーの運用方法など様々な視点のお話しを聞くことができ、とてもためになりました。
- ATgo
- Autify
- mabl
- MagicPod
- Ranorex Studio
ツール比較表
サービス説明を経て、最終的に「 Autify 」「 mabl 」「 MagicPod 」でそれぞれ2週間の期間を設け、PoC（Proof Of Concep）を行いました。PoC中はフェーズを「インストール&環境設定」「テスト実装」「テスト運用」に区切ってオープンロジで本当にツールを利用できるのか、GIに実装されているテストが問題なく移行できそうか等を検証していきました。
PoCシート
※PoC時（2024年の年末頃）NGでも、現在は使えるようになった機能もあるので、機能有無の詳細は各ツール提供会社のHP等をご確認ください
PoCで実際にツールを利用してみると、かゆいところに手が届くツールはどれか、プラン表には利用できると明記されていないが運用で回避できそうとか、使えると思っていたけどシステムとの相性が悪く使えない機能などがよくわかりました。結果として、E2Eテストに特化したシンプルさ、実装・実行時間の早さ、継続できるコスト面のバランスが取れていたMagicPodを採用しました。
初期設定・ルール決め
MagicPodの導入後の初期設定で、何点かつまずいた箇所がありました。
プロジェクトの設定
導入当初は機能毎もしくは目的毎に設定しようと思っていたのですが、よくよくMagicPodの機能を理解すると共有ステップや一括設定はプロジェクト内での共有になるので、オープンロジというシステムに対して１プロジェクトがいいということがわかりました。
上記は MagicPodのスタートガイド 「MagicPodの基本設定とブラウザテストの始め方」 にも記載があることに後日気づきました（笑）
テストケースの整理方法
MagicPodではフォルダを作成することができるため、現状としては目的別のフォルダ内にサブシステム毎のフォルダを作成し、テストケースを格納しています。シンプルな機能ではありますが、フォルダ分けできるのはとても助かります。
組織とプロジェクトおよびテストケース
ラベルの有効活用
ラベルについてはサブシステム毎のラベルと、「Flaky Test」「データ準備」「レビュー待ち」などのテストケースの目的と状況を表す、つまり一括実行でのフィルタリングの条件になるようなラベルを作成していますが、まだまだ活用の余地があると思います。
テストケースと共有ステップの命名規則
MagicPodのテストケース名＝リグレッションテスト のシナリオ名として利用しています。共有ステップについてはサブシステム名 動作 or サブシステム名_画面名 動作という作りにしています。
MagicPod導入前後で変わったこと
テスト実装がしやすい
導入前
GIでは画面のレコーディング or マニュアルでのテスト作成が行えるのですが、Xpathの知識が大前提となっているため、Xpath自体の学習コストと、実装コストがかかっていました。
GIのレコーディング用のツールはChromeの拡張機能としてインストールすることが可能ですが、実際に作成されたテストは可読性に乏しいので、実際に運用する際には修正が必要です。
実際にレコーディングで作ったテスト。何をしてるかわかるかな？
マニュアルでテスト作成する際は、上記スクショのひとつひとつのステップにXpathまたはCSSpathを入力していきます。テスト実装中はGIとは別のウインドウでテストしたい画面を開きながら、ブラウザのデベロッパーツールで要素を一つ一つ特定して入力していくのがかなり手間でした。
また、テストを部分実行する機能がないため、テスト全体を実行してみないとテストが通るか判断できず、実装→テスト→Fail→修正→テストを繰り返すことでのコストもかかっていました。
導入後
MagicPodはテストステップの実装前に画面キャプチャを取得して、画面上のUI要素を特定する仕様になっているため、実装ミスの量が格段に減ったと感じています。また、UIのロケータを複数候補から選択できるため、Xpathの知識が浅い人でもテストを実施するハードルが下がっています。実際の運用では保守性向上の観点から、手直しすることも多いのですが、一からXpathを考えなくていい＆ほとんどのロケータはそのまま利用ができるため、実装スピードが上がりました。
例として https://hotel-example-site.takeyaqa.dev/ja/ さんを利用させていただきました。いつもありがとうございます！
そしてテストの部分実行が可能なため、実装したテストステップのみを実行して実際に動くかを試してみることができます。最小限の時間で、動くテストが実装できているかの検証までできるようになりました。
テスト構成がわかりやすい
導入前
GIではテストは基本的にフラットなリストとして管理され、「スイート」での1階層のグルーピングが基本となっていたため、テストが増えてくると「[機能名]_テストパターン」 のような命名規則に頼るしかなく全体の見通しが悪い状態でした。
またGIではテスト内でのネストが深かったことも可読性の悪さの要因となっていました。
導入後
MagicPodではサブシステムごとにフォルダ分けを行い、テストごとにテスト内で操作するサブシステムのラベルをつけて管理しているため、テストの視認性が上がっています。
MagicPodでは「共有ステップの入れ子の深さの上限」を制限できる（現状は2で設定）ので、その点もテストの把握を楽にしてくれています。
テスト実行速度が速く、安定性も高い
導入前
GIではテスト実行速度に対してテスト環境の描画が間に合わないことが頻発したため、各テストステップに1.5秒の待機をかけていました。全体のテストステップ数が多いため、結果として実行速度の遅延につながっていました。
また、待機ステップのバリエーションが「⚪︎秒待つ」しか存在しなかったため、不要な時間を待ってしまい遅延していた箇所もあります。
導入後
MagicPodは極めてテスト実行速度が高く、安定性も高いです。ツール起因でFailしている箇所がとても少ないので、安心してテスト実行することができています。また、待機ステップのバリエーションも多いため、シチュエーションに合わせた実装を行うことが可能になりました。
将来的には並列実行数も増やして、さらなる実行時間の短縮を目指したいと思いますが、直列実行でも早さを十二分に実感できています。
短いテストを作りやすい
導入前
GIでは一つのテストのステップ数が多くなってしまっていて、最も多いものでは1891ステップ、実行時間は約2時間30分ほどかかっているものがありました。。
導入後
MagicPodはフォルダ分けやラベル付付与によりテストケースの管理がしやすいため、GIよりも細かい単位でテストを作成しています。また、テスト実行回数に制限がないこともMagicPodで短いテストを作りやすい要因になっていると思います。
現在実装しているテストでは長いテストでも大体100ステップ前後、実行時間も＝＝ほどに抑えられているため、テストが失敗した際の原因特定が容易になり、メンテナンスコストの削減に繋がっています。
ツール＆自動テスト運用にあたり工夫したこと
テストアカウントの事前準備
GIでは、各テストの最初にそのテストで使用するアカウントを新規作成するステップを実施していました。大半のテストで実施していたため、単純に実施時間がかかるだけでなく
後述するメールの確認も含んでいたため、メールの結果確認がタイミングよく取得できず不安定となるテストもありました。
MagicPodに移行するタイミングで、テスト内で使用するアカウントは事前に準備をし、テスト実行時のアカウント新規作成は省略する方針にしました。これにより、自動テストは本来のテストしたい内容に集中できるようになるだけでなく、MagicPodのAI要約の内容がシンプルになり、copilotの作業におけるノイズを減らすことができます。
メールテストで利用していたシステムをGmail APIへ移行
元々メールのテストはGIと3rd Partyの別のツールを組み合わせて実現していました。MagicPodに移行したことなどを機に、Gmail APIを利用したメールテストの実行に切り替えました。切り替え時は「 Gmail Web APIを使用してEmailをテストする 」のヘルプページを参照させていただきました。
切り替え作業は社内の情報システム部の力をかりたりと結構大変でしたが、今では以前より安定的に、また、テスト実行速度も早くなったので早い段階で切り替えてよかったなと感じています。Gmailのメールの受信トレイ内の検索方法についてはもう少しいい方法がありそうなので、同じように実装されている方がいらっしゃったら意見交換してみたいです。
リグレッションテストを移行しながらの定期実行
MagicPodでの実装が完了したテストは毎日スケジュールで一括実行を行っています。
一括実行の対象はフォルダだけでなくラベルでも指定ができるため、レビュー前のテストを対象外とすることが容易です。
スケジュール一括実行の結果は完了後slackチャンネルにて通知を行います。落ちているテストは都度確認を行い、安定性が向上するように修正できるかを検討しています。
日次で定期実行する中で、動作が安定しないテストに関しては、一括実行時に他のテストに影響を与える場合があるので、flakyなテストとして他とは別スケジュールで実行することで一括実行の安定性を確保しています。
レビューフロー&レビュー観点の明文化
テスト実装を複数名で行っている＆今後もテスト自動化チームを拡大していく予定があるため、新規テストの実装時や、共有ステップに変更を加えた際のレビューフローを明文化しました。
レビューフローの表
現時点では複数名観点でのレビュアーとして2名配置していますが、将来的にはMagicPod MCPを利用したテストレビューを取り入れ、レビューの自動化にもチャレンジしたいです。
また、レビュー時の観点を一覧化（「同じテストを2回続けて実行できるか」「共有ステップを重複させない」など）しました。レビュー品質を担保し、実装するテストの保守性や元のテストケースとのトレーサビリティを保つための観点となっています。将来レビューを自動化した際のインプットドキュメントにもできればと思っています。
自動化担当以外のQAチームメンバーの声
GIではテストシナリオの作成が属人化していましたが、今回のツール移行に際しては「チーム全員がMagicPodを扱えること」を目標とし、チーム内でワークショップを開催しました。ワークショップでは基本操作からロケータ作成のコツを共有。MagicPodはUIが直感的で、日本語とスクリーンショットで手順が示されるため、参加者も楽しみながら習得してくれました。この理解のしやすさが以前のツールとの大きな差であり、チーム全体のスキルアップに繋がったと感じています。
MagicPodで今後やりたいこと
導入から半年しか経っていませんが、MagicPodの機能も大幅にアップデートされ、MagicPod Autopilotを利用したテストケースの自動生成や修正、MagicPod MCPを利用したテストレビューやテストが失敗した際の原因箇所の特定などにも挑戦していければと考えています。
We Are Hiring!
オープンロジでは一緒に品質課題に向き合っていただけるQAメンバーを大募集中です！
Discussion