MagicPod（E2Eツール）を導入して品質とリリース頻度を両立している話

こんにちは！アルダグラムでエンジニアをしている @sukechannnn です。

アルダグラムの開発チームでは、QAチームを中心にMagicPodを用いてE2E自動テストを追加/運用しています。

このE2E活動をスタートしたのが今年の２月で、約半年かけてある程度の成果が見えるところまで来ました。そこで、私たちがどんな理由でE2E自動テストを運用することにしたのか、それによりどんな成果が得られたのかをこの記事では紹介します。

E2E自動テストの導入を検討している方や、どんなツールを使うか迷っている方の参考になれば幸いです。

なぜE2E自動テストを運用することにしたのか

アルダグラムでは KANNA というノンデスクワーカーに向けたプロジェクト管理アプリを提供しており、Webアプリケーションとモバイルアプリ（iOS / Android）を開発しています。

KANNA は現場の方でも使いやすいアプリになるよう UI/UX をとても大切にしていて、ありがたいことにアプリストアでも高い評価を頂いています。その使いやすさやバグの少なさを支えているのは、間違いなくPdMやQAエンジニアによって行われるリリース前のE2E手動テストです。そのテストで不具合が見つかればリリース前に修正しますし、使い勝手が悪いと判断されればリリースを遅らせてでも修正を行います。

高いUXに寄与している手動テストですが、機能が増えれば増えるほどテスト項目は増え、テストにかかる時間は増えてしまいます。そのため、テスト時間の増加に伴ってバグの発見が遅れ、不具合修正に使える時間が取れず、リリース日を後ろ倒しにせざるをえない…という課題が出てきていました。

この課題を解消し「機能が増えてもリリース頻度を落とさずにかつバグも検知できるような運用体制を作る」ために、そしてその先に「品質を落とすことなくリリース頻度を上げる」ためにE2E自動テストを導入することにしました。

自動テストと手動テスト、それぞれの利点を活かす

E2E自動テストを導入する上で大事なポイントだと思ったのが、自動テストを網羅的に追加しても手動テストはなくならない、ということです。アプリケーションを使う人間がどう感じるか？という感覚の部分については、自動テストでチェックすることはできません。

自動テストで担保しづらい要素としては、例として以下のようなものがあります。

• 実行速度
• 使いやすさ
• UIが動きも含めデザイナーの意図した形になっているか

逆に、自動テストが向いている要素は以下のようなものです。自動テストはプログラムなので、人間と違って同じ動作を繰り返し行うという点では優れています。また、文字の比較などを厳密に行うのは人間よりも得意です。

• システムが意図した挙動をしているか（データの入力/保存/表示）
• システムの挙動が何度繰り返しても問題なく動作するか
• 正しい文言でUIやメッセージが表示されているか、計算結果が正しいか

これらを踏まえて、自動テストの強みを活かすことができ、かつE2Eを追加するコストができるだけ低くなるツールを選ぶことにしました。

E2Eテストツールの選定

E2Eテストツールの候補としては以下の４つがありました。

• cypress
• MagicPod
• Autify
• mabl

前職では Capybara を用いてE2E自動テストを追加していたのですが、E2Eをコードで書いていくのはかなりコストのかかる作業だと感じていました。その経験から、今の開発チームの規模を考えると、テストのプロであるQAエンジニアの方がローコードツールでE2Eを書くのが最適と判断し、cypress は早々に検討から外しました。そのため、主にトライアルを行ったのはそれ以外の３つのツールになります。

ツールを検討する際には「自動テストの強みを活かすことができ、かつE2Eを追加するコストができるだけ低くなるツール」ということで、以下の観点で選びました。

• 使いやすさ/運用のしやすさ
• 何度でも繰り返し実行できるかどうか
• モバイルアプリのE2Eが書けるかどうか

mabl はモバイルアプリのE2Eが書けなかったため、こちらも早い段階で検討から外れました。

Autify は学習コストの低さやテストを追加していく時のストレスの少なさという点ではダントツで良く、実際にKANNAの多くの機能のテストシナリオをトライアル期間中に書くことができました。また、カスタマーサクセスの方も非常に親切で分からないことがあれば丁寧に答えてくださいました。これらはすごく魅力的で見積もりまで行ったのですが、その時に料金体系が実行回数ベースであること、毎日テストを何度も実行しようとすると金銭コストが想定を大きく上回ってしまうことが分かりました。個人的には、システムが行う自動テストは何度でも繰り返し実行できるのが一番の強みだと思っているので、できれば金銭コストを気にしすぎずに実行できるツールだと良いなと思いました。

MagicPod は Autify に比べると若干学習コストが高い印象を受けたものの、操作できる項目が多かったり生のログが見れたりして、使いこなせれば柔軟性の高いテストが書けそうでした。実際にQAエンジニアの方にも使ってみて頂き、何度か一緒に画面を見ながらテストの書き方などを確認したところ問題なく使いこなすことができそうでした。こちらもカスタマーサクセスの方のサポートは手厚いですし、バグの報告をしたらすぐに直してくれてありがたいです。

そして個人的に大きかったのが、MagicPod は実行回数が無制限で、テストシナリオの数に応じて料金が増えていく形式でした（料金プランはこちら）。モバイルアプリのテストも書けるため、私たちの求める「自動テストの強みを活かすことができ、かつE2Eを追加するコストができるだけ低くなるツール」だ！と嬉しくなったのを覚えています。

Autify もよく出来ていたため迷ったのですが、最終的には MagicPod を採用しました。

導入して４ヶ月でどうなったか

いま目指している「自動E2Eテストを活用した開発フロー」は↑上図のような形です。既存機能のシステムが意図通りに動作するかはE2Eで担保し、新機能のテストとUX観点のテストは手動で行います。全てのテストがOKだったら本番にリリースし、新機能のE2E自動テストを追加します。

このサイクルを作ることで、機能がどんどん追加されても手動テスト量の増加を抑え、本質的に手動でテストすべき部分にフォーカスできるようになると考えています。

では導入４ヶ月でどうなったのかというと、Webで使える機能の半分以上が自動E2Eでテストできるようになり、Webフロントエンドの手動テストにかかる時間が30~40%ほど減少しました。とても良い進捗でテスト追加が進んでいますし、自動修復機能のおかげでUIに変更があってもテストが壊れないため、テスト追加後の運用コストがとても低くなっています。自動修復機能はUIに変更があると差分を教えてくれるので、手動テストの時には分からなかった変更を検知することもできるようになりました。

MagicPod ヘルプセンターより

フロントエンドの要素（ボタンなど）を自動検出する機能は不安定なところもあったのですが、エンジニア全員で協力して React のコードに data-testid を追加して回ったのもあって、現在はとても安定しています。

E2E自動テストはステージング環境と本番環境との両方で稼働しています。そのため、意図した変更が本番に正しく反映されているかもしっかり確認できます。また、E2Eは毎日回っているため、リリース前の手動テストよりも早いタイミングでバグに気づけることも増えてきました。網羅的にテストが走っている安心感は、開発の速度を速めてくれるでしょう。

今後はモバイルアプリのテストも追加していく予定です。モバイルアプリの挙動は端末によってどうしても差異が出ますが、MagicPod ではテストを様々な端末で実行できるため、特定の端末でのみ起こるバグにリリース前に気づけるようにしていきたいと考えています。

将来的には、E2E自動テストと手動テストを同時並行で行うことで手動テストにかかる時間を半減させることで、リリースの頻度を倍増させたいと考えています。手動テストと自動テストの良いところをかけ合わせて、クオリティを担保しつつも素早くリリースできる環境を作っていきます！

まとめ

• 自動テストの強みは何度でも繰り返し実行できること
• E2Eは自動テスト/手動テストがあり、全てを自動テストに置き換えることはできない
• MagicPodは実行回数が無制限なので、自動テストの強みを活かせるツール
• MagicPodでほぼコードを書かずにテストを追加し、導入４ヶ月で手動テスト工数の30~40%減少に成功
• （これから）E2E自動テストの割合を増やし、品質を落とすことなくリリース頻度を上げる

どのツールも大変よく出来ていて、その中でも私たちのニーズに合っていたのが MagicPod でした。開発チームによって重視するポイントは変わってくると思うので、とことん試してから決めると良いと思います（どのツールもトライアルの延長に快く応じてくれました）。

E2Eを新たに導入しようと検討している方の参考になれば嬉しいです！