ゼロバンク・デザインファクトリー株式会社(ZDF)の山口です。Application Development Headquarters/Engineering Division1/Backend G1のSETに所属しています。SETはソフトウェアの品質に関する専門性とソフトウェアエンジニアとしてのスキルによって、品質向上と効率化に取り組むチームです。詳しくは以下の記事をご参照いただければと思います。

みんなの銀行のSET（Software Engineer in Test）

SETではこれまで定期リグレッションテスト（※1）で実施するテストを、Appiumを利用しコードを書いて自動化していました。しかし、みんなの銀行の機能追加に自動化が追いついていない課題がありました。これを解決するための手段としてMagicPodの導入に踏み切りました。今回の記事では、MagicPodを選定した理由、導入後数ヶ月経ち感じている効果等をご紹介したいと思います。
これから自動化を進められる方や、同じような課題をお持ちの方、またはノーコードのテスト自動化ツールに興味がある方にとって本記事が参考になれば幸いです。

（※1）定期リグレッションテストでは、現状は障害時に顧客影響の大きい動線をテスト対象とし月に1〜2回実施しています。基本的にモバイル端末や行員画面を操作してのテストを実施しています。

自動化遅延の要因

冒頭に記載した「みんなの銀行の機能追加に自動化が追いついていない課題」についてですが、原因となった要素は以下になります。

テストケースの肥大化

リグレッションテスト対象のケースは、実施必須と定義しているものが約200ケースありました。全体を俯瞰して精査を行い、重複や選定方針から逸脱したケースを実施対象から除外しました。結果として、テストケースを約30%削減しました。しかし、これまで年間平均25件のテストケースが追加されており、今後も継続的な機能追加に伴いその数は増加し続けることが考えられます。

自動化に割ける工数の不足

SETでは自動化のみでなくマニュアルテストを含めた定期リグレッションテストの運営/実施を担当しており、メンバが自動化作業に十分な時間を割けない状況でした。

エミュレーターや実行環境の不安定さ

自動化作業やテスト実行は各人の開発PCで行っており、エミュレーターのバージョンや端末の状態の違いによる問題が頻繁に発生し、作業の中断に繋がっていました。

上記の課題を放置した場合、以下のような状況に陥ることが予想されました。

いつまでもリグレッションテストにかかる工数を削減できない
より高度な仕組み構築（「安定した並列実行環境」「ビジュアルリグレッションの導入」等）や他領域の自動化に手をつけられない
メンバのモチベーション低下

選定要件とMagicPodを選んだ理由

そこで、SETメンバだけでなく開発者やQAメンバ等もテスト自動化に参加できる体制を目指し、専門知識がなくても自動化やテスト実行ができる環境を構築可能なサービスの導入を考えました。そのサービスの選定に当たっては、以下の要件を重視しました。

ノーコード・ローコードのソフトウェアテスト自動化に特化したサービスであること
WEBブラウザのみでなくモバイルアプリにも対応していること
導入実績が多く信頼できるサービスであること

これらの要件に基づき、MagicPodともう1つ別のサービスを検証することにしました。
※ 本記事では、検証を行った時点（2024年）の情報に基づいて執筆しています。最新の情報については、各サービス提供元のWebサイトをご確認ください。

MagicPodを選んだ理由

調査と検証を行った結果、「セキュリティ面」と「料金」と「機能の豊富さ」でMagicPodを選びました。

セキュリティ面

銀行システムとして当然ですが、高いセキュリティレベルを求めます。
MagicPodはセキュアな通信確立が可能なMagicPod Connectを提供しています。MagicPod Connectを利用するとMagicPod側とみんなの銀行それぞれで許可された接続のみを許可する仕組みになっており、これによりセキュリティ要件を満たすことができました。

料金

基本料金については、大きな差はありませんでした。しかし、実行端末追加オプションを利用する想定で概算すると金額に開きがあり、8台追加の場合にMagicPodの概算価格はもう一方の約1/3になりました。

機能の豊富さ

モバイルプランでの比較になりますが、MagicPodは以下の機能で優れており選定の決め手となりました。

ビジュアルリグレッションテストの機能の充実
- 比較除外範囲や許容率の設定の機能があり実用的
API実行ステップ機能の有無
- MagicPodは画面操作の合間にAPI実行のステップを追加することが可能
- UI操作以外の処理も組み込め、テストの自由度・実用性が向上
検証/確認ステップのバリエーションの豊富さ
- 多彩な検証ステップ（要素確認だけでも15種以上）や条件分岐ステップもありノーコードの制約を感じさせない柔軟なテスト作成が可能

導入後の実績/効果

本格的にMagicPodで自動化を開始して約8ヶ月が経ちました。
定期リグレッションテストで実施するテストについて自動化可能なケースについては、80%程度の自動化を終えています。今時点で感じている効果をご紹介します。

自動化実装スピードの向上

自動化したケース数と工数から自動化の実装スピードを計算すると、導入前と後で約3倍になりました。
要素の検出を自動で行ってくれるのは特にありがたみを感じています。待機処理や要素指定において調整が必要な部分はありますが、コードを書くよりも圧倒的に効率良く自動化を進められています。

テストの民主化

普段コードを書かなかったり開発経験がないメンバでも、MagicPodを利用して自動化を行うことができました。今後は"SETでしか自動化できない"という状況が改善されるため、冒頭に記載した「自動化に割ける工数の不足」も課題ではなくなると考えています。

環境の問題改善

MagicPodに実行環境を一任することで、従来問題となっていたエミュレーターの不安定さに起因するテスト失敗は発生していません。また、共通の実行設定を利用しているため、各人の開発PC環境の違いによる失敗も解消されました。さらに、Appiumサーバーや各種ドライバー等を管理といった煩雑な作業からも解放され、これらをMagicPodが担ってくれていると実感しています。

今後の課題

自動化の効果を一層高めるには、以下の2つの課題に取り組んでいく必要があります。

自動化済テストの安定性向上

自動化したテストは必ずしも100%成功するとは限りません。これはMagicPodが原因なのではなく、E2E自動化においてよくある課題と思います。以下のような点をリファクタし安定実行を目指します。

待機処理の考慮
Appium等のコードでは要素の出現を待つ処理を明示的に記述しますが、自分たちのMagicPod利用においては現状はその考慮が出来ていない部分があります。MagicPodにも同等の機能（ステップ）があるため、今後はこれらを活用してテストの安定性を高めます。
実行スケジュールの計画機能の構築
テストケースごとに同時に実施できない項目や前提条件として実施時間帯が決まっている項目があるため、実行スケジュールの自動計画等も行えるよう独自の仕組みを構築できればと考えています。

社内への普及とテストのシフトレフト

MagicPodを導入した効果を最大化するため、社内に普及させ開発段階から組み込むことを目指したいと思います。まずは作成したテストを共有し、定期リグレッションテスト以外の開発中のタイミングでも実行できるようになればと思います。また実行だけでなく、作成も行ってもらえるように利用方法の展開等を行っていきたいと思います。

まとめ

MagicPod導入後、効果が数値として明確に表れています。個人的にも、E2Eテストの自動化に関する課題が一気に解決し、他の業務に集中できる時間が増えました。

また、つい先日MagicPodのMCPサーバーが公開されたことは、今後の展開を考えると非常に楽しみです。AI技術の進化とともにAIを活用した開発がますます重要になる中、E2Eテスト自動化の分野ではPlaywrightのMCPが先んじて注目を集めていました。そのような先進的な技術動向に対し、MagicPodが早くもMCPサーバーを公開したことは、最先端技術への迅速な対応力を示すものであり、大きな強みだと感じています。

今後は、MagicPodのAI対応や業界動向を注視しつつ、様々な技術調査や検証を進め、みんなの銀行の開発プロセスに最適化されたテスト自動化ソリューションを構築していきたいと考えています。より高度な自動化技術の導入を目指し、開発効率と品質のさらなる向上に貢献していきます。