スタンバイQAのテスト自動化導入（MagicPod）

株式会社スタンバイ QAグループに所属している扇谷です。
本記事では、スタンバイQAのテスト自動化の取り組みを紹介したいと思います。
2023年9月現在、導入後1年半におけるスタンバイのWebのテストで、テストシナリオ数は「100個以上」になっており、実施回数は「9000回以上」になります。

テスト自動化が標準となっていく業界の流れの中で、スタンバイQAの目的と試行錯誤から、今後、テスト自動化の導入を検討するQAの意思決定の一助となれば幸いです。

背景・課題　〜　なぜテスト自動化をするのか

スタンバイQAでは、PythonやNode.jsも使用しテストの一部を自動化していますが、本記事ではサードパーティのテストツールの導入についてお話しします。

テスト自動化ツールを導入時には、まずQA費用のコストダウンに注目してしまいがちですが、その前段階として導入によって何を実現したいのか、しっかりと目標を据えることが重要です。
たとえコストダウンが行えなかったとしても、それ以上の恩恵を前提として導入した場合、より幸せなQAライフが待っていると思います。

コストダウンが一番伝わりやすい導入理由になるのを否定するものではありませんが、自動化テストのシナリオ作成やメンテナンスコストを考慮に入れると、コストダウンは必ずしも容易に達成できるものではない可能性があります。

QA予算を抑えることができるようになること
今までQAで実施できていなかった範囲の作業が行えるようになること

図のE2Eテスト部分のコストカットは数字として出しやすいですが、緑色部分はQAチーム外には実感しにくい遅効性の効果だったりしますので、各QA業務のパフォーマンスを数値として出せる（あるいは新しい取り組みを列挙できるよう）準備はしておいた方がいいかもしれません。
内部的なE2Eテストのコストカットを前提としたテスト範囲の拡大を実現し示すことができれば、成長するチームとして組織の中でより存在感のあるQAとなるでしょう。

導入検討　〜　MagicPod を選んだわけ

スタンバイのE2Eテストの自動化導入では、開発状況を反映し、大きく以下の点を達成したいと考えていました。

E2Eテストを開発タスクから「QAタスク」に移行する
以前のスタンバイでは、開発スタッフがE2Eテストを担い自動テストを組んでいました。
QAでも最終的にE2Eテストを実施していましたが、開発段階におけるE2Eテストの一部を実装/実施することは開発サイクルを遅延する一因となっていましたので、開発側のテスト内容をMagicPodに組み込むことで不要なストレスが掛かっていたタスクを取り除くことができました。
ノーコードで作成でき、QA内だけで完結できる
テスト自動化の持続性の点から、自動テストのシナリオ作成は技術的に難易度が低ければ低いほどいいです。
MagicPod社のサポートは手厚いですが、数時間ほどの操作で通常使用に問題ないほどのレベルで習熟ができることは、導入時のとっかかりとして重要です。
E2Eのテスト自動化は、マウスのポチポチだけで達成できる時代が既に到来しており、あらゆるレベルのQAスタッフがそれなりに使用すること自体ができますし、自社の開発スタッフのサポートがほぼ不要なほど僅少で済むことは、QAが自律的に活動できる組織になるための大きな援助となりました。
コスパが良い
機能が必要十分以上であること、継続して開発されていること、従量課金制ではないこと、他サービスと比較し安価であること、など総合的に判断しベンダーロックされても問題ないと判断できました。
従量課金制の場合、金銭的な計算や自動テストの作成や実施回数など気を使わなければいけない部分が出てきます。
テスト回数への制限がないMagicPodの料金体系は、QAが思う理想的なテスト回数を実現できる為、金銭的な憂いから解き放たれることはMagicPodを採用する大きな理由のひとつとなりました。
Android/iOSアプリ対応
2022年の導入当時から、ネイティブアプリのテスト自動化に対応していることも導入の決め手となりました。
コスト感がマッチしていたこと、他サービスを利用した場合には1.5〜2倍超ほどコストがかかる可能性があったことも後押しとなりました。

これらを持って、数社のサービスを比較しMagicPodの無料体験から導入を決めています。

恩恵　〜　望外に便利だった機能

画像差分比較
MagicPodでは、キャプチャした画像を期待値として、テスト実行時に比較し差分を検出/通知できます。
スタンバイでは、リリースサイクルの兼ね合いからQAを通さずにABテスト等を実施する必要もあった為、本番環境と検証環境で定期的に実行してくれるMagicPodは導入意義が高くありました。
リリース後の不具合を検出できるか否か以前に、画像差分でABテスト部分の差分を教えてくれることで、QAが絡まないリリース内容を開発↔︎QA間での事前/事後の情報共有/確認が不要となりました。
現行のプロダクトを早期に正確に把握できること、かつ本来必要なコミュニケーションを不要なものとして昇華してくれたことは、QA作業の負荷を軽減してくれたと思います。
メールチェック
公式サイトで外部連携のメールチェックの手法が2種紹介されていますが、弊社ではSlackのチャンネル用のメールアドレス宛にメールを送信しています。
普段使いのSlackでメールを簡易に確認できることは、シナリオ作成時においても利便性が良かったです。
日次の検索やクリックを行う
スタンバイのサービスでは、クリック履歴や検索履歴から作成されるデータがあるのですが、検証環境では開発/QAスタッフがメインに触っていますので、操作履歴の絶対量が少なく確認したいタイミングでデータがない場合がありました。
前日や当日の下準備が必要となっていたのですが、MagicPodが毎日、決まった時間にアクセスやクリックを頑張るシナリオを作成することでそのような下準備が不要となり、仮に反映されない現象が発生した場合に、どのタイミングから発生したのかを遡りで原因を特定することも容易になりました。

メリット・デメリット　〜　メリットを大きく引き出す

スタンバイではMagicPodの自動実行を、本番と検証の両環境で3時間ごとに回しています。

前述の「今までQAで実施できていなかった範囲の作業が行えるようになること」として可能な限り頻度を高めていきたいのと、テスト結果確認におけるタスク量を許容できる範囲に収めるバランスの落とし所として頻度を決めています。

別途、新規実装のテスト環境でも手動実行を行なっており、今まではテスト依頼ごとに広範でのリグレッションテストやE2Eテストは実施できていませんでしたが、MagicPod導入によりテストカバレッジが増加しました。
スタンバイQAとしては、コストカットよりQAが行える作業量の拡大とコストカット分の時間を他作業に当てることを主眼に置いていましたので、当初の目標は早い段階で達成できたかと思います。

なお、デメリットというデメリットはありませんが、導入時のテストシナリオ作成のタスク量は大きい為、繁忙なQAチームのタスク軽減を目指して導入したのにテストシナリオ作成が滞る可能性は起きうるかと思いますし、スタンバイでも導入直後はその状態にありました。
QAチームの置かれている状況を考慮に入れ、取捨を行いテストシナリオ作成を優先することで数ヶ月〜1年後に想像していた未来を手に入れることができると思います。
デメリットよりもメリットを享受できる未来に持っていくまでのロードマップを正しく描き、正しく実践することが重要かと思います。

反省　〜　導入に向けて気を付けること

スタンバイQAのMagicPod導入時に試行錯誤の上、手戻りが発生した点は以下となります。
端的には、誤った前提から始まるテスト作成は、メンテナンス性の悪さから無用の長物と化してしまう可能性が高いです。

E2E・リグレッションのテスト項目は作り直すべき
通常、テスト項目数は機能追加と共に右肩上がりとなり取捨選択が必要となっていますが、テスト自動化の導入により基本的に整理する必要性は低下していきます。
MagicPodのシナリオはテスト手順が多くなりますので、どのようなテストを行なっているかの確認は時間を要しますので、別管理がおすすめです。
また、手作業でテスト項目を埋める際には順不同でも確認できれば問題ないですが、自動化したチェック順と実際のテスト項目の順番に齟齬が発生していると実装内容が追加/改修された時にメンテナンスが煩雑になります。
弊社の導入時を省みても、作業の流れを意識したテスト項目の完成度の高さがスムーズなテストシナリオ作成と以後のメンテナンスコストの軽減に繋がることを、当たり前のことながら強くお伝えしたいと思います。
テストシナリオは小分けにすべき
長すぎるテストシナリオは、テスト結果の確認時にどの機能でアラートされているか判断するのが手間になります。
小分けしすぎるのも問題ですが、冗長なテストシナリオは確認やメンテナンスも煩雑になるので、機能ごとに区切って適切なボリュームに収めて作成することが重要となります。

これらを実践することで、E2E・リグレッションテストの精度も向上し、MagicPodのメンテナンス性も高まります。
導入を機会に、可能であれば項目を見直し刷新すると良いでしょう。