Ubie Discovery でエンジニアをしている @guchey です。
症状検索エンジン「ユビー」はiOS/Androidアプリ版も提供しており、リグレッションテストにMagicPodを導入しています。
今回はMagicPod導入の経緯とUbieでの活用事例についてお話しします。
MagicPodとは
MagicPodは、モバイルアプリテスト、ブラウザ(ウェブアプリ)テストの両方に対応したAIテスト自動化クラウドサービスです。
個人的には以下の特徴が気に入っています。
- テスト実行回数が無制限である
- テストシナリオの作成が直感的で簡単
PoC的に導入したのですが、1日程度で自動テストをCIで実行できる状態に持って行けたのでそのまま継続利用しています。
Ubieのアプリ開発の課題
Ubieではcapacitorjsを使って、症状検索エンジン「ユビー」を開発しています。Web/iOS/Androidを横断して一つのコードベースで開発できることでユビーの高速開発を支えています。
Capacitorの導入経緯に関しては以下のスライドで詳しく紹介していますので、興味があればご覧ください。
症状検索エンジン「ユビー」の特徴として、Capacitorからリモートサーバーにアクセスを行う構成になっています。
ストアへのアップロードを伴わない簡易なアップデートができる反面、リモートサーバーとアプリ間で参照しているコードベースのバージョンに差が発生するようになり、不具合[1]の原因になることがあります。
そのため、リモートサーバーとアプリ、それぞれの独立したバージョンアップでリグレッションテストが必要です。
一方で、Ubieには症状検索エンジン「ユビー」の開発を行う複数のチームが存在しますが、開発に携わる全てのエンジニアがアプリの開発環境を持っているわけではありません。そこで、リグレッションテストのうち、重要なポイントに関して自動テストを導入することにし、MagicPodを試験導入しました。
Capacitorアプリでは自動テストツールには何を選択すべきか？
WebViewベースでリモートサーバーからの配信である点から、Cypress.ioのようなブラウザE2Eテストソリューションも考えられますが、課題で挙げた通り、アプリのバージョンとの組み合わせで不具合が発生しうることから、実機でのテストが必要です。
ionicチームがCapacitorでのE2Eソリューションに関して言及しています。
appiumのようにテストコードを書くために独自の知識が必要なツールも考えられますが、Ubieでは複数のチームが存在するため、操作が直感的など、メンテナンスの運用負荷が小さい点も重要でした。（E2Eサービスを導入したが、メンテナに一部のエンジニアしかいなく、運用面でスケールしない状況を避けたかった。）
MagicPodはその点でUbieのユースケースに合致しているように感じました。
活用事例
テストシナリオ作成
ドラッグ&ドロップでUIパーツを操作＆アサーションできるのが直感的でいいと感じます。
CapacitorはWebViewベースですが、MagicPod上ではロケータを意識することなく利用できています。
CIとの連携
不具合の原因になりがちな、リモートサーバーとアプリでコードベースに差が生じるタイミングでMagicPodを利用した自動リグレッションテストを実行しています。
具体的には以下のケースです。
- Webのデプロイアクションの後
- Appのデプロイアクションの後
GitHub Actionsとの繋ぎこみには便利なAPIClientがあるため、こちらを利用します。
以下は簡単なサンプルです。
- name: Setup magicpod
shell: bash
run: |
curl -L -O "https://github.com/Magic-Pod/magicpod-api-client/releases/download/${RELEASE_VERSION}/linux64_magicpod-api-client.zip"
unzip -q "linux64_magicpod-api-client.zip"
env:
RELEASE_VERSION: 0.99.3.1
- name: Run test
shell: bash
run: ./magicpod-api-client batch-run -S ${{ inputs.test-settings-number }}
env:
MAGICPOD_API_TOKEN: ${{ inputs.api-key }}
MAGICPOD_ORGANIZATION: ${{ inputs.organization }}
MAGICPOD_PROJECT: ${{ inputs.project }}
PR毎にリグレッションテスト
アプリ本体に修正が入る場合はPR毎にリグレッションテストを実行したいです。
アプリのビルド、アップロードまで同じアクションで実施し、app_file_numberで直前にアップロードしたバージョンを指定してテストを実行できます。
PR毎のテストでは、MagicPodが実行回数無制限であることが嬉しいですね。
- 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 }}
結果の見える化
また、テストの実行結果に関しては誰の修正・リリースをトリガーに実行されたテストなのかをわかりやすくするために、メッセージをカスタマイズしてSlackに配信しています。
普段の開発業務での認知負荷を減らしつつ、問題が起きた時はアプリのことも思い出してもらえるような工夫です。
まとめ
MagicPodを導入したことで、開発におけるエンジニアの認知負荷を低減でき、Capacitorが持つクロスプラットフォームでの生産性の高さをさらに発揮できるようになったと感じます。
まだまだ簡単なユースケースでしか利用していませんが、今後は
- テストシナリオの拡充
- 定期実行
- テスト実行時間のモニタリングと改善
- Web/App複数バージョンでの組み合わせのテスト実行
あたりも進めていきたいと考えています。
UbieではソフトウェアエンジニアとQAエンジニアが協力しながら品質担保の取り組みを進めており、自動テストだけでなく、開発プロセスの改善に一緒に取り組んでくださるQAエンジニアを募集しています。
是非カジュアル面談からお気軽にお問い合わせください。
-
例えば位置情報を取得するコードがリモートサーバーから配信されたとしても、アプリは位置情報の取得に対応していないバージョンのままであることがあり得ます。 ↩︎
Discussion