技術部品質向上グループのきしけん（@takeya0x86）です。 今回の記事ではトクバイアプリの自動テストについてお話ししようと思います。
これまでのトクバイアプリのE2E自動テストについて
トクバイアプリでは、アプリとバックエンドそれぞれでユニットテストやAPIテストが存在し自動化されています。しかし、アプリからバックエンド全体を通したE2E自動テストについては整備されていませんでした。前回の私の記事では、まず手動でのリグレッションテストを整備し、自動化については今後の課題にしていました。ここではテストの自動化について、ツールの選定から現在の運用について解説します。
ツール選定・Magic Podについて
Magic PodとはTRIDENT社が提供するSaaS型の自動テストサービスです。今回はAppiumなどを使用する場合との比較を行い、こちらのサービスをメインに使うことに決定しました。主な選定理由としては以下の点が挙げられます。
- クラウド環境でテスト実施可能
- ノーコードでテスト作成
- CIとの連携
順に見ていきましょう。
クラウド環境でテスト実施可能
スマートフォンの端末を使用した自動テストを行う場合、手元で端末と母艦となるPCとを接続して管理することになります。現在はリモートワークが中心ということもあり、オフィス内に実行環境を作ってもメンテナンスが難しいという状況がありました。また、Appiumをはじめスマホアプリの自動テストツールはOSの新バージョンがリリースされるたびにアップデートが必要になります。これはAndroid SDKやXcodeも含むものであり、依存ツールの不整合などで毎回トラブルが起きがちです。
Magic Podを利用した場合、これらの管理の煩雑さをサービス提供側が請け負ってくれます。個人的には最も気に入っている点です。
ノーコードでテスト作成
Magic Podではノーコードでテストを作成することができます。
上記の編集画面のように、右側に各UI要素がスキャンされたスクリーンショットが表示され、このUI要素を左のエリアにドラッグすることでテストを作成していきます。Appiumでは -ios class chain=**/XCUIElementTypeButton[name == "ログイン"] といったロケータを調べる必要がありましたが、これをあまり意識せずに、UIを見て直感的にテストを作成することができます。
CIとの連携
トクバイアプリではCIとしてBitriseを使用しています。Magic PodにはBiriseに連携するためのワークフローが用意されており容易に連携ができます。
トクバイアプリにおいての運用方法
テストケース数・実行時間
現在はAndroid、iOSそれぞれにおおまかな機能カテゴリごとにテストケースを作成しています。テストケース数は10程度、ケースあたりのステップ数はやや機能によって開きがあり、50~100くらいです。実行時間はAndroidで20分、iOSで45分程度です。
実行方法
Bitriseのジョブをトリガーとして実行しています。実行タイミングは以下の二つです。
- デイリー実行
- 特定ブランチへのマージ時
デイリーの定期実行は夜間のNightly buildに対して実行しています。特定ブランチへのマージ時は、 develop ブランチやリリース準備用の RC-** ブランチにアプリのコードがマージされたタイミングで実行しています。テストの実行時間が長いためコミットごとなど高頻度での実行はやっていません。
テストデータ作成バッチ
トクバイで表示するデータはスーパーなどのチラシ・商品情報です。これらのデータはおおむね1日から3日で入れ替わります。「当日限り」や「タイムセール」といった一定時間しか表示されない情報もあります。そのためテストデータも実データに近づけ、毎日バッチで作成するようにしています。
使ってみての所感
良かったところ
良かった点は前述の選定理由とほぼ同じです。前職でAppiumの環境構築を何度もやっていた身としては、これをお任せできるだけでかなり楽だと感じました。
結果レポート
実行結果は以下のようなレポートが出力されます。
URLを共有するだけでチームに見てもらえるのでこちらも楽です。
要望への対応
Magic Podはユーザと運営サイドのやりとりがSlackでできるようになっており、質問や要望を投げかけることができます。位置情報を使用した機能のテストが上手く動かない旨を報告すると、ほどなく対応してもらえました。こういった点も助かっています。
気になるところ・欲しい機能
逆に気になっているところやこれがあると嬉しいなという点です。
タイミングによって失敗することがある
テストを実行した時、スワイプや画面遷移の微妙なタイミングで失敗することがあります。UIを使うテストでは起こりがちな現象ですが、このあたりを上手く処理することができるとテストの安定性が上がって良いかなと思っています。
テストの編集履歴管理
Gitでソースコードの履歴を管理するように編集履歴を管理できたり、特定のバージョンに簡単に戻せるようになっているとできることが広がります。現在は最新版しか保持できないため、アプリの改修で画面が変わった場合などに新旧両方の画面に対応するテストを作るのが難しいです（条件分岐などを使えば一応可能）。
Slack通知
今はメールをSlackに送信する形で連携していますが、直接Slackに通知する機能がほしいですね。
自動テストの今後について
最後に今後やっていきたいことについてです。
現状ではビルドの結果はBitriseに、テストの結果はMagic Podにと、情報が散らばっています。これらを上手く紐づけて、ビルドのリビジョン番号やプルリクエストとテスト結果を簡単に見られるようにしたいです。コードに対する変更の量とテスト結果がどんな関連を持つかなどが履歴として管理できているような状態を作りたいと思っています。
テストの内容についてですが、トクバイアプリではチラシや商品の閲覧があるとログを送信するようになっています。これは集計されてスーパーなどのカスタマーへのレポートの情報源になります。したがって、欠損や重複があるとカスタマーに対し正確な情報が提供できなくなるという事態が発生します。これを防止するためログのテストを実施するのですが、現在これを自動化するために試行錯誤しているところです。このログはバックグラウンドで送信され、基本的に画面上に表示されるものではないためMagic Podのようなツールでテストするのが難しいです。
リグレッションテスト全体の見直しも考えています。自動化されたテストが増えた分、エンジニアが手を動かしてテストする時間は減らしていくことができます。依然として手動でしか確認できない領域はありますが、上手くバランスをとってより良い時間の使い方ができるように改善していきたいです。
おわりに
現在ロコガイドで実施している自動テストの一部について解説しました。ユーザーのみなさんに、より安定して使いやすいサービス・アプリをお届けできるようこれからも活動していきたいと思います。
