©MIXI 家族アルバム みてねの 安定リリースを支える MagicPod活用状況 2023/07/14 みてねプロダクト開発部QAチーム　森島　諒

©MIXI 2 自己紹介 森島　諒 / もりしま　りょう 2021年10月ミクシィ（現 MIXI）入社 みてねブログ • みてねQAチームの取り組み • みてねのE2E自動テスト導入戦略

©MIXI 3 ※1iOS・Android™アプリ登録者数、ブラウザ版登録者数の合計 ※2「みてね」登録時に入力されたお子さまの誕生日と厚生労働省発表「人口動態統計」から算出。 　　2022年8月時点で47.1％。 スマホで撮った子どもの写真や動画を家族と共有し コミュニケーションして楽しむ家族アルバムサービス 利用者数が1,500万人※1 を突破!!(2022年8月時点) 日本国内ではママやパパの約半数となる47.1％の方※2 に ご利用いただくサービスとなりました 家族アルバム みてね

©MIXI 4 みてねの品質管理体制と 現在のMagicPodの利用状況

©MIXI 5 みてねの品質管理体制 • QAチーム体制 • QAエンジニア：3名 • ブランチ戦略 • トランクベース開発：小さな変更を頻繁にトランク(mainブランチ)にマージする • リリースサイクル • 2週間のリリーストレイン • 実施するテスト • PR駆動テスト： • PullRequestごとにビルドを作成して機能・回帰テストを実施、問題がなければmainにマージ • QAによるテストをするかどうかは、開発者自身にて判断してもらう • リリース前テスト： • 回帰テスト：iOS/Androidアプリのリリース前にQA用ビルドで実行する主要機能の回帰テスト • 本番スモークテスト：Androidのみ本番用ビルドが起動できるか確認する超簡易テスト

©MIXI 6 MagicPodの導入 • 2022年4月から本格導入開始（約1年利用中） • 導入体制 • 1人をMagicPod導入担当にする • 手動テストは導入期間中はできる範囲で代わってもらう • 導入期間 • 3ヶ月 • プロジェクト • Android（2022年4月導入） • iOS（2022年10月導入） • 実行端末種類 • クラウド端末のみ • 詳細な導入戦略はブログへ！ • みてねのE2E自動テスト導入戦略

©MIXI 7 • Android アプリ • 一括実行設定の種類 MagicPodの実行状況 名前 トリガー 実行数 主なテスト内容 実行時間 実行並列数 簡易テスト 検証用ビルド作成ごと（自動） 3-4回 / 日 最低限の主要なテスト 約30分 3台 フル回帰テスト ナイトリービルド作成ごと（自動） 1回 / 日 全ての回帰テストを実行 約3時間 4台 リリース前テスト リリースビルドが作成されたら 手動アップロード、手動実行 2回 / 月 リリースにマストな回帰テスト 約2時間 3台 スモークテスト 本番用ビルド作成ごと（自動） 2回 / 月 アプリ起動テスト 約2分 1台 • CI連携 • CircleCIのビルド作成後のステップに、MagicPod連携のステップを追加（MagicPod APIを利用） • ビルドアップロード • テスト実行 • テスト開始のSlack通知（QAチャンネルに通知） • テスト結果のSlack通知（QAチャンネルに通知、MagicPodのSlack通知機能を利用）

©MIXI 8 MagicPodの実行状況 • iOSアプリ • 一括実行の種類 • Flakyなテストを取り除く取り組み • ビルドを更新せず、日次でリリース前テストを実行 • 思わぬテストの失敗が多く、テストの安定性を高めるため • iOSのE2Eテストの課題 • シミュレーター向けビルド作成の自動化、CI連携ができていない • シミュレーターのリセットに時間がかかる • テストケースごとにリセットする運用はしづらい 名前 トリガー 実行数 主なテスト内容 実行時間 実行並列数 リリース前テスト 手動でビルド作成 手動アップロード、手動実行 1回 / 日 リリースにマストな回帰 テスト 2時間 4台

©MIXI 9 MagicPodの恩恵 • リグレッションテストにより予期せぬ不具合の発見につながっている • 特にAndroidは、マージ後の不具合発見〜修正までが短くなった • 毎日実行されていることでリリース前の安心につながっている • メンテナンスに手間はかかるが、リリース前も慌てず安心して過ごせる • リリース前テストが誰でも簡単にボタン１つで実行できるようになった • ライブラリなどのアップデートが楽になった • 以前は、サーバーのRubyアップデートに、1週間以上かけて手動回帰テストをしていた • この工数の確保が難しく、実施できる期間も限られていた • いまでは、実施したいときに検証環境にデプロイして、深夜のMagicPodテストの結果を見て 翌日リリース！ • エンジニアにも認知が広まり、実行やテスト自動化を依頼されることも増えてきた！ • QAもエンジニアも参加しているチャンネルに実行結果を流すことで 自然と興味を持ってもらえた

©MIXI 10 • 2週間ごとにメンテナンス担当を設定して交代している • 日々の実行で失敗があったら、担当が確認→切り分け→メンテナンスまで実施する • UIが変わったり、環境要因など様々な理由で失敗は多々ある… MagicPodの日々のメンテナンス

©MIXI 11 MagicPodの運用例

©MIXI 12 MagicPodの運用 - 共有ステップを使い倒す • ほぼ共有ステップを利用してテストケースを作成 • 1ステップしかない共有ステップもある • メリット • テストケースの作成が簡単になる • 何をしたいのか名前でわかるので、可読性が上がる • メンテナンスが楽 • デメリット • 同じ共有ステップを違う名前で作ってしまう • 変更差分の履歴は共有ステップごとに確認が必要

©MIXI 13 MagicPodの運用 - 1テストケースで複雑なパターン実行 • テストケース数の節約術として実施していた • データパターンにシナリオを登録して、シナリオごとにテストケース内で条件分岐する • メリット • 似たようなテストケースが量産されない • データパターンにシナリオがひと目で見える • デメリット • テストケースに条件分岐が多くなり可読性が落ちる • 初見で理解ができない

©MIXI 14 MagicPodの運用 - 一括実行はすべてラベル管理 • ラベルは、一括実行の単位として利用 • 並列実行もラベルを使って分けている • Androidは適当に負荷分散するよう振り分け、iOSはシナリオごとに振り分け Androidのテストケース一覧 iOSのテストケース一覧

©MIXI 15 MIXIのMagicPod利用状況 • 開発本部QAがMIXI全体で、MagicPodを利用できるようにしてくれている • みてね以外にも、さまざまなプロダクトで利用中！ • 先月はMIXI QA内の自動化コミュニティで知見共有会を実施しました • MagicPodの困っていることを共有して解決できたり発見がいっぱい

©MIXI