MagicPodを1年運用して気づいたおすすめしたいポイント
はじめに
QAエンジニアとして自動テストを中心にプロダクト品質向上のために日々活動しています。
MagicPodを導入から運用まで約一年経って、導入時に考えていた以上のおすすめしたいポイントに気づけたので紹介したいと思います。
MagicPodはモバイルアプリのテストで利用していたので、ブラウザには当てはまらないこともあるかもしれません。
これから導入を検討している方の一助になれば幸いです。
導入時に考えていた重視していたポイント
MagicPodはテスト実行回数が無制限です、何回実行しても料金が変わることはありません。この点が非常に魅力的でした。
実際に導入してみた後も実行回数無制限は威力を発揮していて、高速なリリースを支えるためには必須です。
理由の一つとして、自動テストをリリース前に実施する用途で導入される場合があると思いますが、E2Eテストは安定性に課題がある場合が多く、いざ実行したときに失敗するとその切り分けに時間がかかります。テスト側の問題もあれば、再現性がなく失敗することもあるので、再実行して確かめたいわけです。そんなときに実行回数を気にしないといけないのは、リリース前の緊張感の中で多大なストレスです。
こちらに関してはMagicPodは期待通り以上で、いまではリリース前どころか毎日実行・ビルド毎実行など高頻度でテストができている状態を作り出すことができたのでリリース前に大慌てすることも少なくなりました。
運用後に気づいたMagicPodをおすすめしたいポイント
クラウド端末がいつでも利用できる
MagicPodは、クライアントはWebブラウザさえあればテストを実装することができます。アプリのインストールなどは必要なく、ご自身のPCでシミュレーターを立ち上げたり、ブラウザが占有されることはありません。これはテスト一括実行だけでなく、テストを実装するときにも使えることが嬉しい点で、本番実行するときとほぼ同じ環境がすぐに再現できることと、実装者のPCスペックに依存せずに快適に利用できることで、作成から実行、運用まで助けになっています。
共有ステップが作りやすい
MagicPodは、UIをクリックすることで要素を自動取得し、項目を選択することでスクリプトを作成していくようなテスト実装フローです。
この点は使い始めは慣れなかったり、自動取得した要素（XPath）を修正することが初心者には難しかったりと、いわゆるキャプチャーリプレイの自動化ツールと比べると実装に少し乗り越える壁があります。
ただ言い換えると、要素の取得を助けてくれて後は自分でカスタマイズができるので、とても自由度が高いです。これは共有ステップを作るときに活きていきます。
共有ステップを作るときは、別の箇所でも使うことを意識して共有化するのですが、一方で成功しても、もう一方では失敗してしまうことは往々にしてあります。そのときには項目だけ統一したいときには要素を引数にすることができたり、汎用化するようXPathを調整できます。
上記のような点で、共有化が捗り、チームで利用しやすくなっていく点が魅力的でした。
画像差分比較（ビジュアルリグレッション）をテストの中に差し込める
画像差分を確認するステップがあり、テスト内で特定の箇所に差し込める点が魅力です。通常のテストに画像差分を確認することができるので、それぞれを別に考える必要がない点はありがたいです。あとからこの箇所に画像差分を入れたいときにも対応できたり、画面の項目が多くて確認ステップを作る量が多くなるのでサボりたい…という怠惰な私にも画像差分比較ステップ１つで簡易的に代用できたりします。（あとでちゃんと直してます。）
テスト結果の表示が速くわかりやすい
テスト一括実行をするときはスクリーンショットを取得でき、取得タイミングもいくつか選択できます。
E2Eテストは安定性に課題があり、実際に失敗も多いです。（２回目）テストが失敗したときに素早く確認して速くリリースしたいので、原因を素早く掴めることが重要です。
私の場合は、スクリーンショットを各ステップで取得にしていたので、テスト結果のページを表示すると、ステップごとにスクリーンショットが並んでくれています。時系列でそのときの状態が見てとれるので原因特定に役立っていました。スクリーンショットがたくさんあってもページの表示にストレスを感じない程度に速いこともとても助かっています。
ただ、スクリーンショットのタイミングがステップ実行後なので、場合によってはまだページ遷移中にスクリーンショットが撮られていたりして状態がわからなかったりする点は課題です。上位プランでもいいので、実行中の様子を録画して再生できる機能があったりすると強力なサポートになりそうです。
また、失敗したステップのスクリーンショットを保存して、テスト作成にそのまま利用できます。これは、ちょっとだけ間違ったり変わってたりするときに、またイチから該当の箇所まで再現してテストを修正する必要がないので時短につながっています。
AIが自動修正した内容がわかりやすいことも魅力です。AIが要素の変更などを検知してテスト中に自動修正した内容を自動的にテストに反映するのではなく、要確認の保留状態になり前回と今回の違いを並列でスクリーンショットで表示してくれます。その内容を目視で確認したあとに承認するので、人間が作業せずに判断するだけでいいというのは本当にすばらしいです。
日本の企業であること
MagicPodは日本の企業なので、日本語のサイト・ヘルプ・サポートがある点はチーム運営する点では展開速度に影響したと考えています。地味ですが変数名に日本語が利用できたときは嬉しかったです。
ユーザーコミュニティも日本語が主で、ユーザーMeetupも日本で開催のため交流が取りやすく情報交換が捗ります。MeetupにはMagicPodのエンジニアの方を含めいろんな職種の方が参加してくれて、直接生の声を届けられることはなかなか貴重で、日本語で交流できて嬉しいです。
最後に
本当は他にもサポートのレスポンスが早いこととか、機能リリースが早いこととか色々書きたいことはありますが、長くなりそうなので今回はここで終わろうと思います。
私の運用経験から気づいたおすすめしたいポイントが、これから導入を検討する方の一助になれば幸いです。
今回の記事はMagicPodがバージョン1.0到達した記念のキャンペーンに便乗したのですが、いつもブログやユーザーLT会などの機会を作ってくれるMagicPodの方々には感謝したいとともに、応援しているサービスが節目を迎ておめでとうの気持ちが届くといいなと思っています。