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

Transcript

1. Ubieのアプリ開発を支える自動テスト
   2023/09/28 モバイルアプリの開発生産性を上げる
   Lunch LT
   田口信元
   

   View Slide

2. 2
   自己紹介
   2021年にソフトウェアエンジニアとして Ubieに入社。現在はtoC向
   けのプロダクトである症状検索エンジン「ユビー」、基盤サービスの
   開発や、開発生産性向上に取り組んでいる。
   田口　信元
   @ShingenTaguchi
   

   View Slide

3. 3
   ３．自動テスト導入と運用
   目次
   １．症状検索エンジン「ユビー」の技術スタックと開発体制
   ２．開発・運用時の課題
   ４．まとめ
   

   View Slide

4. 4
   症状検索エンジン「ユビー」の紹介
   ● 自身の症状から関連する病気や近隣医療機関を
   調べられるサービス（ Web/iOS/Android）
   ● 2020年5月に正式公開、現在 700万MAU
   ● TypeScript+Next.js / Kotlin+SpringBoot /
   GraphQL / Capacitor
   ● Androidアプリ「ヘルスコネクト」との連携で血糖
   値のデータを元にした質問をしたり等も
   症状検索エンジン「ユビー」の技術スタックと開発体制
   利用者
   月間
   700万
   

   View Slide

5. 5
   Capacitorとは
   ● WebViewベースのクロスプラットフォームアプリのフレームワーク
   ● Web技術（HTML / CSS / JavaScript）で開発する
   ● Ubieの場合はNext.jsのブラウザ版が既に存在していた
   ○ Webの既存資産がある場合に活用して素早くアプリ化できる
   ● WebViewからリモートサーバーにアクセスすることでブラウザ版と同じ感覚でモバイルアプリを開発できる
   症状検索エンジン「ユビー」の技術スタックと開発体制
   

   View Slide

6. 6
   Capacitorとは
   ● モバイルアプリ版からネイティブの機能を使いたい場合はプラグインを経由して利用できる。独自のプラグイ
   ン開発も可能
   ● ヘルスコネクトのプラグインは独自に開発（ ubie-oss/capacitor-health-connect）
   症状検索エンジン「ユビー」の技術スタックと開発体制
   

   View Slide

7. 7
   ● フロントエンドエンジニアが多く、アプリエンジニアが少ない
   ○ プロダクト開発のうち、ネイティブの機能の利用頻度は低い
   ○ 少ないリソースでモバイルアプリを維持する必要がある
   ● チームトポロジーをベースとしてチームを分割。責任境界を明確に。
   ○ Web技術でブラウザ版/モバイルアプリ版のプロダクト開発を進める複数のストリームアラインドチーム
   ○ Capacitor、プラグイン等のメンテナンスを行うモバイルアプリプラットフォームチーム
   フロントエンドエンジニアメインの開発体制
   症状検索エンジン「ユビー」の技術スタックと開発体制
   モバイルアプリ
   プラットフォームチーム
   ストリームアラインドチーム A
   ストリームアラインドチーム B
   ストリームアラインドチーム C
   

   View Slide

8. 8
   開発・運用時の課題
   

   View Slide

9. 9
   開発・運用時の課題（ストリームアラインドチーム）
   開発・運用時の課題
   理想
   ● ブラウザ版 / モバイルアプリ版問わず、 Web部分でほとんどの機能を開発・動作確認できる
   ● ネイティブ部分を利用する場合は実機で開発・動作確認する
   現実
   ● ネイティブの機能の利用頻度は低い。 意図せずにネイティブ部分に依存する機能を変更をしてしまいアプリ
   がクラッシュ。お叱りのレビューをいただくことも‥
   ● Web部分の開発は活発で、必要な時に実機で動作確認する運用ではバグを見逃してしまう
   ○ そもそも実機動作確認の環境を整えるのも大変
   ● ブラウザ版に追従して手動でモバイルアプリのテストを行うのが現実的ではなくなってきた
   

   View Slide

10. 10
    開発・運用時の課題（モバイルアプリプラットフォームチーム）
    開発・運用時の課題
    ● CapacitorのWebViewからリモートサーバーの Next.jsにアクセスしている特有の辛さがある
    ● Web部分のリリースとアプリのアップデートにはラグが発生する
    ○ アプリのCapacitorのバージョンとリモートサーバーの Capacitorのバージョンが異なることがあり、後
    方互換性が無いアップデートをするとアプリがクラッシュしてしまうことも
    ● 手動テストを実機での自動テストに置き換え、開発生産性を下げずに、認知負荷を下げつつ、品質も担保し
    たい
    

    View Slide

11. 11
    自動テストの選択肢
    開発・運用時の課題
    ● ブラウザ / モバイルアプリのハイブリッド開発の利点として、開発者はほとんどの体験をブラウザで検証でき
    るので、自動テストも Cypress.io / playwright のようなブラウザE2Eテストソリューションが大部分で利用で
    きる
    ○ しかし、実機でのテストが重要と考えていたためこれだけでは不十分
    ● 運用コスト軽減のため、テストメンテナンスの容易さ、手元に実機を用意せずに済む点が重要
    ● サービスの開発が活発なので、頻繁に E2Eテストを行いたい
    ○ テスト実行回数が無制限なのが決め手で MagicPodを導入
    

    View Slide

12. 12
    自動テスト導入と運用
    

    View Slide

13. 13
    自動テストシナリオ
    自動テスト導入と運用
    ● ネイティブ部分を利用する主要な導線に絞って
    E2Eシナリオを作成
    ● WebViewベースのアプリでも、ロケータを意識す
    ることなく利用できるので学習コストは低い
    

    View Slide

14. 14
    ● ストリームアラインドチーム（ Web部分の変更をする場合）
    ○ ネイティブアプリのリリースなしで、 Web部分だけ最新化するケース
    ● モバイルアプリプラットフォームチーム（ネイティブ部分の変更をする場合）
    ○ Webのリリースなしで、ネイティブアプリをリリースするケース
    テストのタイミング（ストリームアラインドチーム）
    自動テスト導入と運用
    

    View Slide

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
    

    View Slide

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 }}
    

    View Slide

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
    

    View Slide

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 }}
    

    View Slide

19. 19
    ● テストの実行結果に関しては誰の修正・リリースをトリガーに実行されたテストなのかをわかりやすくメッセー
    ジを整形してSlackに投稿
    ● 普段の開発業務ではあまり意識しないモバイルアプリに問題が起きた時は思い出してもらえるようにしていま
    す
    テスト実行結果の通知
    自動テスト導入と運用
    

    View Slide

20. 20
    導入後の結果
    自動テスト導入と運用
    ● 現在では1日に10回程度モバイルアプリの E2Eテストが実行されている
    ○ 今までに合計で4821回実行された
    ○ 毎回手動でテストしていたら相当の工数になったはず
    ● 事前に検知できたバグは数回
    ○ パーミッション許可ダイアログの表示不具合
    ○ モバイルアプリ版の意図していなかった画面遷移の不具合
    ● 開発生産性を下げずに認知負荷を下げつつ品質を担保できている
    

    View Slide

21. 21
    まとめ
    

    View Slide

22. 22
    まとめ
    ● フロントエンドエンジニアメインで、ブラウザ版 / モバイルアプリ版 を高速に開発している Ubieの事例を紹介
    ● Ubieの場合は、フロントエンドエンジニアがモバイルアプリを意識しすぎることなく、品質が担保されることを
    目指した
    ● Howに囚われすぎず、自社の技術との親和性、チームの理想的な状況と現在とのギャップからどの部分を
    自動化するか、どう運用するかを考える
    ● We’re hiring!!
    

    View Slide