はじめに： MagicPod を使った、E2E の継続運用をふりかえって
こんにちは。サイボウズ Office の iOS 製品 の QA の玉木( gkzz )です。 本記事では、E2E 自動テストの SaaS のひとつである MagicPod を使い始めてから3年目に突入したので運用の経験をご共有できればと思います。
特に以下のようなお悩みを抱えている方に向けて、本記事が一助となればうれしいです。
- E2Eテストを自動化したいけれど運用で苦労している
- モバイルアプリの回帰試験の負担軽減の取り組みがなかなか続かない
- MagicPod の現場運用事例を知りたい
第三者目線に立ってのふりかえり
ある自動テストツールを導入してみたというお話はちらほら見かけますが、その後の後日談、とりわけ苦労話はあまり見かけません。私や私が所属するチームでも E2E の自動テストとの向き合い方にとても試行錯誤しました。
そこで、この記事では第三者目線で MagicPod というE2E の自動テストツールを運用してきたことのふりかえりとして書いていきます。
（ふりかえりをしたからといって、MagicPod の運用をやめるというわけではなく、今後もガシガシ使っていくつもりです。念のため。）
本記事のスコープとこれまでの経緯
最初に、本記事のスコープをお伝えさせてください。
- MagicPod を用いたモバイルアプリの E2E 自動テストの「運用体制の構築」と「継続運用」における実践的な工夫・課題共有
- チームでテスト自動化運用を進める際の、知見・ノウハウ・改善サイクル
- 運用フェーズで発生する具体的な悩み（属人化・テストの不安定さ・工数分散など）とその対応策
- MagicPod の現場運用を2年間続けてきた経験から得られた学びや今後の展望
続いて、これまでの経緯についてもかんたんにご紹介させてください。
冒頭で少し触れたように、私たちのチームでは2年前に Magic Pod を導入し、以後継続して自動テストの運用に取り組んでいます。
※導入期の取り組みについては下記の資料で詳しく説明していますので、あわせてご覧ください。
導入当初は私が専任で自動テストの開発・運用を手がけていたのですが、途中から自動テスト運用と QA 業務を兼務するようになり、徐々に稼働が逼迫するようになりました。
また、私が一手に運用を担当しているがゆえに、自動テスト運用についてのナレッジがチーム内に蓄積されないという弊害も見え隠れし始め、私の一人運用からチームメンバー全員を巻き込んでの運用にシフトする取り組みに着手しようという話が持ち上がりました。
チームで運用前夜
焦点をあてたい課題
毎日の結果確認と落ちたテストケースの修正が軌道に乗り始めたタイミングで、スプリントの QA 業務も並行して取り組むことにチャレンジしました。平常時は問題なかったのですが、複数のテストケースが落ちると、途端に毎日の結果確認と落ちたテストケースの修正に追われ、一気に私の稼働が逼迫しました。
この問題の背景には、実装で使用されている共通コンポーネントの画面変更に追随する必要があったことがあります。専任での対応には限界があり、効率的な運用が求められていました。
このような背景から、E2E 自動テストの運用を個人からチーム体制に移行し、課題を共有しながら解決策を模索する取り組みが始まりました。
チームで運用期
はじめに認識合わせ
チームで MagicPod の運用を本格的に始めるにあたり、最初に行ったのが「認識合わせ」です。個人からチーム体制への移行に際し、現状の課題と目指すべき方向性をメンバー間で共有しました。特に、専任時代に発生していた「稼働の逼迫」という課題をチーム全体で共有し、改善策を話し合いました。また、MagicPod 主催のセミナーに参加し、メンバー間の知識を平準化しました。
チームで運用期間にやり始めたこと
稼働の逼迫を解消させるべく、以下の改善策を導入してみました。
- 当番制の導入: 毎日の結果確認を当番制にし、作業負担を分散
- タスク管理の強化: テスト失敗時の修正タスクをチームのタスク管理アプリに登録し、対応漏れを防止
- 属人化の防止: 修正タスクは対応可能なメンバーが自主的に担当し、チーム全体で対応
- 心理的負担の軽減: 修正はその日に完了する必要がないという合意形成により、心理的負担を軽減
- ナレッジの共有: 作業手順や運用方法をドキュメント化し、誰でも参加しやすい環境を整備
成果
これらの改善策により、専任時代の稼働逼迫を解消し、効率的な運用が可能になりました。チーム合意による心理的負担の軽減や、メンバーのスキル向上により、迅速かつ効率的に対応できる体制が整いました。
メンバーからは、「工数がカツカツになったことはない」、「結果確認はスムーズに行えるようになったが、修正タスクの偏りがある」といった意見があり、これらをもとにさらなる改善を続けています。
新たに浮上した課題
一方で新たな課題も以下のとおり浮き彫りになりました。
- テストケースやフォルダ、ラベルの管理が複雑化し、新メンバーが全体像を把握するのに時間がかかるようになった
- 情報の増加に伴い、整理が追いつかなくなったことが原因
- テストの実行時間が長い
- 特に開発スピードが求められるプロジェクトではストレスの一因となりうる
- 環境依存やネットワークの不安定さによるテストの失敗があり、テスト結果の信頼性が損なわれかねない
今、取り組んでいること
改善業務
これらの課題に対処するため、以下の改善業務に取り組んでいます。
- テストケースの構造を分析し、可視化を進める
- 命名規則を見直し、新しいラベルを導入して分類を明確化
- 待機処理を見直し、不要な操作を削減して実行時間を短縮
- Flaky なテストを撲滅するため、環境とネットワーク依存の改善を実施
課題解決の文脈から離れますが、新規テストケースの追加作成にも取り組んでいます。
今後の展望
MagicPod では対応が難しい領域を補完する手法（例：XCUITest の併用）を検討しています。ログイン後に複数操作を要するシナリオでは、事前状態のセットアップや OS レベルの操作の活用により、テストの実行時間短縮を図っていきたいです。これにより、柔軟性と堅牢性を両立したハイブリッドなテスト戦略を構築できるでしょう。
自動化の効果は継続的に確認していきます。運用負荷の軽減、実行や確認のスピード、テストの安定性、対応のしやすさといった観点で、定性的・定量的に捉える方針です。なお、目的が既存機能の動作維持の確認であることから、新規不具合の件数は主要な評価軸とはしません。得られた示唆は定期的にふりかえり、テスト設計や運用（当番制・タスク管理・ドキュメント化など）の改善に反映していきます。
※テスト結果は kintone アプリなどで管理することが多いです。実データの掲載は控えたいので参考資料を併記させてください。
まとめ
MagicPod を2年間運用してきた経験を通じて、E2E テストの自動化には多くの課題があることを実感しました。しかし、チームでの運用や改善業務を通じて、これらの課題に対処し、より効率的で信頼性の高いテスト体制を構築することができました。今後も、さらなる改善を続け、より良い品質保証体制を目指していきます。
