hey Product Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

STORES ECに自動テストツールのMagic Podを導入した話

はじめに

STORES EC ( ※ 以降、EC )のバックエンドエンジニアの@fuqdaです。

先日、Magic Podという自動テストツールを本格導入したので、今回はその当時の状況と実際に試してみた所感をレポートしたいと思います。

QAでお悩みの方はぜひ最後までご覧ください。


f:id:fuqda:20210912132853p:plain


前提

  • ECの開発では、「実装フェーズ」と「リリース」の間に「QAフェーズ」という期間を設けてアプリケーションの品質を担保するようにしています。

    • ※ 小案件では簡略化することもあります。
  • ECの開発では、基本的にエンジニアがQAを行います。

  • ECでは現在、7環境(PC 4ブラウザ、iPhoneiPadAndroid)で動作確認を行なっています。

導入当時の状況

ECは2012年にスタートしたサービスで、年々増える画面・機能によってQAにかかるコストも段々無視出来ない規模になってきました。
直近、私たちのチームで感じていた主なQAの課題感は以下の通りです。


  • サポート対象全てのブラウザ・端末での動作確認にかかるコストが高い

  • テストケース作成が手間

    • 多いと数千ケースに及ぶことも...

f:id:fuqda:20210919222225p:plain

  • テストケース毎に必要なテストデータの用意が面倒

    • テストケースが多いのでテストデータも色んなパターン必要

上記の中でも最低限 サポート対象全てのブラウザ・端末での動作確認 のコストを下げることを目標に Magic Pod を導入しました。

他サービスとの比較結果

導入に当たって決め手になったのは以下の4点でした。

  • マルチブラウザ・モバイル対応
  • 機能と価格のバランスが取れていること
  • 実行回数の制限が無いこと
  • Slackルームなどサポート面が充実していること

当時チームが抱えていた課題として、マルチブラウザ・モバイルの動作確認コストが高いことがあったので、その部分の解消が見込めることやその他機能とコスト面とのバランスが決め手になりました。

また、各サービスの比較結果は以下の表にまとめましたので、参考にしていただければと思います。

なお、各サービス毎の価格については公表されていないため触れていません。詳細を知りたい方は各サービスにお問い合わせください。

サービス名 テストケース作成の容易さ テストデータ作成の容易さ サポート ブラウザ・端末対応 実行回数
Autify △ (テストケース毎にデータを事前に用意しておく必要がある)
mabl ○ (Web APIコール機能を使ってテストケース毎にデータ投入可能) × (検証時点ではモバイル端末は非対応) ◎ (ローカル実行無制限 / クラウド実行回数は要問い合わせ)
Magic Pod ○ (Web APIコール機能を使ってテストケース毎にデータ投入可能) ◎ (クラウド環境でも同時2端末まで実行回数無制限・ローカル実行無制限 )

Magic Podって何?

Magic Podは、モバイルアプリテスト、ブラウザ(ウェブアプリ)テストの両方に対応した自動テストツールです。

※ モバイルアプリテストとブラウザアプリテストは別契約になります。

本稿で触れていない部分をもっと詳しく知りたい方は公式ドキュメントやその他資料も合わせてチェックしてみてください。

公式ドキュメント📝

デモ動画

Magic Pod のテスト作成、実行については以下の動画をご覧になるとイメージが湧くと思います。

※ ブラウザテストではなくiOS Appのテストの様子ですが、ブラウザテストもほぼ変わりません


www.youtube.com

Magic Podの特徴

  • BrowserStack Automate との連携で、macOS, Windows のOSを指定、実行するブラウザも各主要ブラウザをバージョンを指定して実行することが可能

    • BrowserStackクロスブラウザ(OS含む)による動作確認を手軽に行える環境を提供しているサービスで、Automate はその中の機能の一つ
  • ビジュアルリグレッションテストも用意されており、環境構築なしでチェックできる

  • テスト実行が無制限でできる

    • ローカル環境の実行回数無制限
    • クラウド環境でも同時2端末まで実行回数無制限
    • 他サービスでは実行回数に制限がある上にローカル実行不可の場合も
  • 料金も他サービスと比べると比較的リーズナブルなので導入しやすい

  • 公式Slackルームが用意されている

f:id:fuqda:20210918142424p:plain

実際にやったこと

  • 実装箇所のテストケース作成

  • BrowserStack Automateと連携したマルチブラウザの動作確認 (クラウド実行およびローカル実行)

    • Google Chrome / Safari / Firefox / Microsoft Edge の確認
    • ※ 今回はモバイル端末は実機で確認
  • テストケース全てを一括実行

    • その日の終わりにテストケースを全て流して落ちないことを確認するようにしました。

f:id:fuqda:20210920231212p:plain

良かったこと

  • 手元でブラウザを切り替えずにマルチブラウザの確認が出来るのですごい楽

    • Magic Podでは検証が難しいテストケースは手動で確認する必要がありましたが、それでも相当数のケースでマルチブラウザの確認が自動化されたインパクトは大きかったように思います。
  • デグレ確認が容易だった

    • QAフェーズに発覚したバグは優先度高いissueであればすぐ修正するのですが、ある箇所の変更が関連箇所に影響を及ぼしてないか確認する際に、すでに作成してあるテストケースをそのまま流せばデグレ確認が簡単に出来るのは心強かったです。
    • QAフェーズでは毎日終業間近に全てのテストケースを一括実行して重大なバグがないかをチェックしながら進めたので以前のリリースよりも「デグレしてない!」という部分に安心感を持って開発を行うことが出来ました。

困ったこと

  • 画面によっては要素のXPathを指定しないとAIが正しく要素を認識してくれない場合がある

    • XPathを指定することで解決出来ることに気付くまで時間を溶かしてしまいました。
  • クラウド環境でテスト実行した時にランダムでテストが落ちる場合がある

    • BrowserStack Automateと連携して、各ブラウザを回してみるとよくわからないところでfailすることがありました。
    • 「安定するようにテストケースを見直す」のか「そこは諦めて手動でやる」など進めていく悩ましい部分も出てきたので、基本はテストケースを直しつつ、ケースバイケースで柔軟に進めました。
  • 一括実行は完了までにそれなりの時間がかかる

    • 今回 Magic Pod上で作成したテストケースが約50個で、1ケースの実行に1分程度かかっていたので全部通すのに50分ほどかかっていました。

      • ※ Magic Podはテスト実行時にブラウザ選択が出来るので、50個 * ブラウザ数 をカバー出来るのですが、一括実行時はChromeだけで全ケース流すに留めていました。
    • 私たちの使い方として退勤1時間前ぐらいに一括実行して、その日の修正でデグレがないことを確認するだけだったのでセーフでしたが、CIに組み込むには実行時間的に厳しそうな気がします。

QAで手動からMagic Podに置き換えることが出来たテストケース数は?

最近リリースのあった案件のテストケース数

  • 887件

Magic Podで自動化出来たテストケース数

  • 392件

半分には届きませんでしたが、全体の44% を自動化することが出来ました 🎉
これを多いと取るのか少ないと取るのかですが、今まで手動でやっていた確認項目が半分程度になるだけでも十分に導入の意味があったように思います。

Magic Podが得意なこと / 苦手なこと

最後にMagic Podを利用していて、コレは得意!コレは苦手!など感じた部分を独断と偏見でまとめて終わりたいと思います。

得意なこと

  • 画面の表示内容の確認

    • 「〇〇のデータを持つユーザーが遷移すると〇〇ボタンが表示されること」のような単純なテストでは手動で複数ブラウザ切り替えながらやるよりもスムーズだったので有用でした。
  • 画面遷移の確認

    • 「特定の操作後に〇〇の画面に遷移すること」のようなケースも上記同様にMagic Podに任せて、手動確認は複雑なケースに集中するのがスピードも出て良いと感じました。

苦手なこと

  • 外部APIを挟んだ処理のテスト

    • 動作確認が可能なケースと難しいケースがあるので、手動で動作確認すると割り切りました。
  • テストケースの管理

    • 現状のプランでは最大3つプロジェクトを作れるのですが、テストケースのカテゴリーを作ってグルーピングすることが出来ないので作成済みのテストケースの管理には工夫が必要な印象でした。テストケース毎にラベルを付けれるため、今回はその機能を使ってグルーピングしましたが、テストケースが増えると一覧がかなりゴチャゴチャして来るので、この部分は今後のバージョンアップに期待です。

    • 上記のことからも、Googleスプレッドシートで管理していたテストケースをMagic Podに全て委譲することは出来ませんでした。

おわりに

やってみた感想としては、Magic Pod導入後のデビュー戦だったのでツールに慣れる時間を要したものの、慣れてくれば手動QAを愚直に行うよりも遥かに速度を出すことが出来そうに思いました。

一回テストケースを作成することで、関連処理をいじった際もデグレ確認が一瞬で終わるのが個人的にすごく気に入ったポイントです。

今回試したのは、Magic Podの機能の一部なので、次回以降の案件ではまだ試せてない機能もフル活用しながらQAプロセスの改善に取り組みたいです。