Ubieのアプリ開発を支える自動テスト

Transcript

1. Ubieのアプリ開発を支える自動テスト 2023/09/28 モバイルアプリの開発生産性を上げる Lunch LT 田口信元
2. 2 自己紹介 2021年にソフトウェアエンジニアとして Ubieに入社。現在はtoC向 けのプロダクトである症状検索エンジン「ユビー」、基盤サービスの 開発や、開発生産性向上に取り組んでいる。 田口　信元 @ShingenTaguchi
3. 3 ３．自動テスト導入と運用 目次 １．症状検索エンジン「ユビー」の技術スタックと開発体制 ２．開発・運用時の課題 ４．まとめ
4. 4 症状検索エンジン「ユビー」の紹介 • 自身の症状から関連する病気や近隣医療機関を 調べられるサービス（ Web/iOS/Android） • 2020年5月に正式公開、現在 700万MAU • TypeScript+Next.js / Kotlin+SpringBoot / GraphQL / Capacitor • Androidアプリ「ヘルスコネクト」との連携で血糖 値のデータを元にした質問をしたり等も 症状検索エンジン「ユビー」の技術スタックと開発体制 利用者 月間 700万
5. 5 Capacitorとは • WebViewベースのクロスプラットフォームアプリのフレームワーク • Web技術（HTML / CSS / JavaScript）で開発する • Ubieの場合はNext.jsのブラウザ版が既に存在していた ◦ Webの既存資産がある場合に活用して素早くアプリ化できる • WebViewからリモートサーバーにアクセスすることでブラウザ版と同じ感覚でモバイルアプリを開発できる 症状検索エンジン「ユビー」の技術スタックと開発体制
6. 6 Capacitorとは • モバイルアプリ版からネイティブの機能を使いたい場合はプラグインを経由して利用できる。独自のプラグイ ン開発も可能 • ヘルスコネクトのプラグインは独自に開発（ ubie-oss/capacitor-health-connect） 症状検索エンジン「ユビー」の技術スタックと開発体制
7. 7 • フロントエンドエンジニアが多く、アプリエンジニアが少ない ◦ プロダクト開発のうち、ネイティブの機能の利用頻度は低い ◦ 少ないリソースでモバイルアプリを維持する必要がある • チームトポロジーをベースとしてチームを分割。責任境界を明確に。 ◦ Web技術でブラウザ版/モバイルアプリ版のプロダクト開発を進める複数のストリームアラインドチーム ◦ Capacitor、プラグイン等のメンテナンスを行うモバイルアプリプラットフォームチーム フロントエンドエンジニアメインの開発体制 症状検索エンジン「ユビー」の技術スタックと開発体制 モバイルアプリ プラットフォームチーム ストリームアラインドチーム A ストリームアラインドチーム B ストリームアラインドチーム C
8. 8 開発・運用時の課題
9. 9 開発・運用時の課題（ストリームアラインドチーム） 開発・運用時の課題 理想 • ブラウザ版 / モバイルアプリ版問わず、 Web部分でほとんどの機能を開発・動作確認できる • ネイティブ部分を利用する場合は実機で開発・動作確認する 現実 • ネイティブの機能の利用頻度は低い。 意図せずにネイティブ部分に依存する機能を変更をしてしまいアプリ がクラッシュ。お叱りのレビューをいただくことも‥ • Web部分の開発は活発で、必要な時に実機で動作確認する運用ではバグを見逃してしまう ◦ そもそも実機動作確認の環境を整えるのも大変 • ブラウザ版に追従して手動でモバイルアプリのテストを行うのが現実的ではなくなってきた
10. 10 開発・運用時の課題（モバイルアプリプラットフォームチーム） 開発・運用時の課題 • CapacitorのWebViewからリモートサーバーの Next.jsにアクセスしている特有の辛さがある • Web部分のリリースとアプリのアップデートにはラグが発生する ◦ アプリのCapacitorのバージョンとリモートサーバーの Capacitorのバージョンが異なることがあり、後 方互換性が無いアップデートをするとアプリがクラッシュしてしまうことも • 手動テストを実機での自動テストに置き換え、開発生産性を下げずに、認知負荷を下げつつ、品質も担保し たい
11. 11 自動テストの選択肢 開発・運用時の課題 • ブラウザ / モバイルアプリのハイブリッド開発の利点として、開発者はほとんどの体験をブラウザで検証でき るので、自動テストも Cypress.io / playwright のようなブラウザE2Eテストソリューションが大部分で利用で きる ◦ しかし、実機でのテストが重要と考えていたためこれだけでは不十分 • 運用コスト軽減のため、テストメンテナンスの容易さ、手元に実機を用意せずに済む点が重要 • サービスの開発が活発なので、頻繁に E2Eテストを行いたい ◦ テスト実行回数が無制限なのが決め手で MagicPodを導入
12. 12 自動テスト導入と運用
13. 13 自動テストシナリオ 自動テスト導入と運用 • ネイティブ部分を利用する主要な導線に絞って E2Eシナリオを作成 • WebViewベースのアプリでも、ロケータを意識す ることなく利用できるので学習コストは低い
14. 14 • ストリームアラインドチーム（ Web部分の変更をする場合） ◦ ネイティブアプリのリリースなしで、 Web部分だけ最新化するケース • モバイルアプリプラットフォームチーム（ネイティブ部分の変更をする場合） ◦ Webのリリースなしで、ネイティブアプリをリリースするケース テストのタイミング（ストリームアラインドチーム） 自動テスト導入と運用
15. 15 • 各環境へのリリース後に github actions 経由で毎回モバイルアプリの E2Eテストを実行 ◦ 最新バージョンのモバイルアプリを利用し、リリースされた Webにアクセスする • github actionsからの呼び出しには Magic-Pod/magicpod-api-client を利用 テストのタイミング（ストリームアラインドチーム） 自動テスト導入と運用 release run e2e test test ios test android notify result rollout web build web image latest version App
16. 16 • 各環境へのリリース後に github actions 経由で毎回モバイルアプリの E2Eテストを実行 ◦ 最新バージョンのモバイルアプリを利用し、リリースされた Webにアクセスする • github actionsからの呼び出しには Magic-Pod/magicpod-api-client を利用 テストのタイミング（ストリームアラインドチーム） 自動テスト導入と運用 runs: steps: - name: Run test shell: bash run: ./magicpod-api-client batch-run -S ${{ inputs.test-settings-number }} env: MAGICPOD_API_TOKEN: ${{ secrets.MAGICPOD_API_KEY }} MAGICPOD_ORGANIZATION: ${{ inputs.organization }} MAGICPOD_PROJECT: ${{ inputs.project }}
17. 17 • ネイティブ部分に変更が入った場合はプルリクエスト毎にリグレッションテストを実行 ◦ アップロードしたモバイルアプリを利用し、最新バージョンの Webにアクセスする テストのタイミング（モバイルアプリプラットフォームチーム） 自動テスト導入と運用 release #1 run e2e test #1 test ios #1 test android #1 notify result latest version web build app #1 upload app #1
18. 18 • ネイティブ部分に変更が入った場合はプルリクエスト毎にリグレッションテストを実行 ◦ アップロードしたモバイルアプリを利用し、最新バージョンの Webにアクセスする テストのタイミング（モバイルアプリプラットフォームチーム） 自動テスト導入と運用 runs: steps: - name: Upload app and run test shell: bash run: | FILE_NO=$(./magicpod-api-client upload-app -a ${{ inputs.upload-app-path }} ./magicpod-api-client batch-run -S ${{ inputs.test-settings-number }} -s "{\"app_file_number\":\"${FILE_NO}\"}" env: MAGICPOD_API_TOKEN: ${{ inputs.api-key }} MAGICPOD_ORGANIZATION: ${{ inputs.organization }} MAGICPOD_PROJECT: ${{ inputs.project }}
19. 19 • テストの実行結果に関しては誰の修正・リリースをトリガーに実行されたテストなのかをわかりやすくメッセー ジを整形してSlackに投稿 • 普段の開発業務ではあまり意識しないモバイルアプリに問題が起きた時は思い出してもらえるようにしていま す テスト実行結果の通知 自動テスト導入と運用
20. 20 導入後の結果 自動テスト導入と運用 • 現在では1日に10回程度モバイルアプリの E2Eテストが実行されている ◦ 今までに合計で4821回実行された ◦ 毎回手動でテストしていたら相当の工数になったはず • 事前に検知できたバグは数回 ◦ パーミッション許可ダイアログの表示不具合 ◦ モバイルアプリ版の意図していなかった画面遷移の不具合 • 開発生産性を下げずに認知負荷を下げつつ品質を担保できている
21. 21 まとめ
22. 22 まとめ • フロントエンドエンジニアメインで、ブラウザ版 / モバイルアプリ版 を高速に開発している Ubieの事例を紹介 • Ubieの場合は、フロントエンドエンジニアがモバイルアプリを意識しすぎることなく、品質が担保されることを 目指した • Howに囚われすぎず、自社の技術との親和性、チームの理想的な状況と現在とのギャップからどの部分を 自動化するか、どう運用するかを考える • We’re hiring!!