株式会社VoicyにおけるMagicPod導入と活用

ツール導入前の課題

• 新機能が増えるたびにテストケース数も増加し、リリース前に手動で実施していたリグレッションテストが、1日で終わらなくなりつつあった。
  • 2種類のモバイルアプリを提供しており、合計で2000件以上のリグレッションテストケースがあった。

どのような状態を目指していたか

• 最低限のユーザー体験を継続的に担保すること
  • すべての機能を網羅的に自動化するのではなく、よく使われる主要シナリオから順にカバーする。
• 安全にリリースできる状態を、持続可能なコストにキープすること
  • 「リグレッションテストの実行コストを下げる（例：X人日 → Y人日）」と定義し、その実現手段としてE2E自動テストツールの導入を決定した。

• Appium
• mabl
• Autify

【重要視していた観点】

• セットアップのしやすさ
• サポートの手厚さ
• プラン・料金

【上記以外の観点】

• モバイルネイティブアプリ対応
• モバイル独自の機能への対応有無
• 実装方法（ノーコード/ローコード/自身でコーディング）→テスト作成の難易度が自組織に合っているか
• テスト環境との接続方法、テスト実行方法（専用のテスト実行環境が必要か、社内の検証環境で実行できるか）
• テスト結果の振り返りのしやすさ
• 他ツールとの連携（CIパイプラインからのテスト実行、テスト結果の通知）

【セットアップのしやすさ】

• iOS/Androidともに約15分ずつでセットアップが完了！ サクッとテストを作成・実行できる環境が整った。

【サポートの手厚さ】

• トライアル期間に、ログイン（メールでの認証が必要）や有料コンテンツの購入（外部サービスとの連携が必要）のテストを作成した。
• つまづいた時に、迅速にそして丁寧にサポートいただいた。
• これなら、続けられそう！と思えたのが決め手となった。

【プラン・料金】

• 最低継続利用期間がなく、1ヶ月から利用できる。

どのような成果が得られたか

【よく使われる主要シナリオから順にカバー】

• 10機能の自動化を半期目標として掲げていた。
• 導入2ヶ月目から、手動リグレッションテストのケースを一部MagicPodでの実行に切り替えられている。

【リグレッションテストの実行コストを下げる】

• 導入3ヶ月後時点で、毎回、約40ケース分を削減できている。

1.テストの粒度

• 機能ごとにでテストを作るか？
• 一連のユーザー行動ごとにテストを作るか？

例えば、ログイン、プレミアムリスナーの加入という機能の単位でテストを作っていくのか。 新規ユーザーがアカウントを登録してから最初の放送を再生する、というシナリオでテストを作っていくのか。

まずは小さなパーツとして各機能を自動化し、いずれ大きなシナリオを作れる状態にしていくこととした。

2.再生できたことをどのようにアサートするか

• Voicyのアプリの特性上、できれば音声が再生されたことを確認したい。

しかし実際に音が出ているかを確認することは困難。
そこで、音声が出るかは自動テストでは確認せず、代替案として、一時停止ボタンが表示されていることをアサートすることにした。

3.テスト実行開始前後で、データの状態を一致させる
当初は、特定のアカウントを使い回すことを考えていた。しかし、どんどんコンテンツを購入すると、購入したコンテンツを再生する際に操作が複雑になりそうだった。そこで、テスト内では毎回新規アカウントを作成し、意図したコンテンツがいつもリストの一番上など決まった場所に表示されるようにした。
（変数を活用し、メールアドレスに現在時刻を含めることで、毎回異なるメールアドレスでアカウント登録ができる）

• 新しく配布されたビルドに対して、自動でテスト実行する
• テストの拡充
• 属人性の排除