株式会社オープンロジのMagicPod導入事例

導入背景

オープンロジのQAチームでは、E2Eテスト自動化に4年ほどGhost Inspector (GI) を利用してきました。しかし、自動テストが属人化していたため、全体像を把握し課題の洗い出しを行った結果、使用ツールの変更を行うことにしました。

ツール導入前の課題

（移行前のツールで抱えていた主な課題）

1. 実装コストと属人化:
   • Xpathの知識が前提となっており、学習・実装コストが高かったです。
   • レコーディング機能で作成したテストは可読性が低く、結局修正が必要でした。
   • テストシナリオの作成が属人化していました。
2. 検証の手間:
   • テストの部分実行機能がなく、テスト全体を実行しないと動作確認ができませんでした。
   • テストのサイズが大きく、Fail時の修正→確認のサイクルにコストがかかっていました。
3. 実行速度と安定性:
   • テスト実行速度に対してテスト環境の描画が間に合わないことが頻発したため、回避策として各ステップに1.5秒の待機を入れていたことにより実行時間が長くなっていました。
   • 待機ステップのバリエーションが「⚪︎秒待つ」しかなく、不要な待機も発生していました。
   • テスト内で使用するアカウントを毎回新規作成しており、時間がかかっていました。
4. 管理の複雑さ:
   • テストの管理がフラットなリスト管理（1階層のグルーピング）しかできず、テストが増えると全体の見通しが悪くなっていました。
   • 一つのテストが長大化（最大1891ステップ、実行時間2時間30分）し、失敗時の原因特定が困難でした。

• Autify
• mabl

• 以下の点でAutify、mabl、MagicPodの3ツールでPoCを実施しました。
  • E2Eテストに特化したシンプルさ
  • 実装・実行時間の早さ
  • 継続できるコスト面のバランス

上記3つの「バランスが取れていた」ことが、MagicPod採用の最終的な決め手になりました。

改善したかった課題はどれくらい解決されたか

1. 実装コストと属人化
   • 画面キャプチャベースでUI要素を特定・選択できるため、Xpathなどの知識が浅くても実装のハードルが下がりました。
   • UIが直感的（日本語とスクリーンショット）で、チーム内でのキャッチアップが容易で、属人化の解消につながっています。
2. 検証の手間
   • テストの部分実行が可能になり、最小限の時間で動作検証ができるようになりました。
3. 実行速度と安定性
   • MagicPodは実行速度が速く、安定性も高い（ツール起因のFailが少ない）です。
   • GIで必須だった1.5秒の待機が不要になりました。
   • 待機ステップのバリエーションが多いため、状況に合わせた効率的な待機実装が可能になりました。
4. 管理の複雑さ
   • フォルダ分けやラベル付けでテストケースの管理がしやすくなりました。それにより細かい単位でテストを作成し（長くても100ステップ前後）、メンテナンスコストが削減されました。