モバイルアプリにおけるE2Eテストの自動化

こんにちは、QAの木下です。
この記事では、ウェルスナビで実施している総合テストのうちの一つ、モバイルアプリのリグレッションテストを自動化し、工数の削減に成功した話について紹介します。

モバイルアプリのテスト自動化を検討する前の状況

ウェルスナビでは、Webサービスへの結合テストと総合テスト(リグレッションテスト)に対して、手動によるテストとAutify for Webによる自動テストを実施しています。
その結果、QAメンバーは、テスト実施の作業から、要件定義時に想定される不具合の発見やテスト設計への注力のシフトができつつあります。
一方でモバイルアプリへのテストに対しては、結合テスト・総合テストともに手動によるテストを継続していました。
QAメンバーは、テスト設計から結合テストの実施、総合テスト(リグレッションテスト)の実施に、多くの工数がかかっていました。
そこで、安定的に案件を回せている間に、モバイルアプリのテストにかかる工数を削減するための施策として、モバイルアプリのテスト自動化を試みました。

モバイルアプリのテスト自動化ツールの候補

モバイルアプリのテストに利用できるサービスを探し始めたところ、知見の豊富さ、サービスの歴史の長さやサポートの手厚さの観点から、検討段階で以下の候補が挙がりました。

• Appium
  • 2011年に開発が始まり、2014年に正式リリース
• Autify for Mobile
  • 2021年10月iOSに対応し、2023年2月Androidに対応した、テスト自動化プラットフォームを正式提供開始
• Magic Pod
  • 2017年7月iOSとAndroidに対応した、テスト自動化プラットフォームを提供開始

ただモバイルアプリのテスト自動化ツールの採用には、ウェルスナビ特有の課題があり、課題を解決できるサービスを選定する必要がありました。

テストケースで画面要素の特定が困難

ウェルスナビのモバイルアプリの開発現場では、iOSとAndroidは個別に開発が行われています。
開発時、ユーザー操作ができる要素(ボタンなど)に対して共通の ID の割当を行っていないため、開発者によって画面を実装する際に違った構造となっています。
そのため、テスト実施に不可欠な要素の一意な特定が難しいため、iOSとAndroidで共通のテストシナリオとなるテストフレームワークの導入ができませんでした。

モバイルアプリ開発に精通した技術者がQAメンバーに不在

またQAメンバーの出身背景として、開発経験が全員有していない、また開発経験がある場合でもSwiftやKotlinの開発経験がないメンバーで構成されています。
そのためQAメンバーが、テストケースをネイティブコードで実装する対応ができないため、iOSとAndroidそれぞれが有するテストフレームワークの利用はできませんでした。

モバイルアプリのテスト自動化ツールの選定決定

ウェルスナビでは、以下の理由によりオーティファイ社が提供する「Autify for Mobile」を採用しました。

• 開発時に、画面要素の特定の必要がない
  • 自動テストシナリオ作成時、画面内の要素を操作する際に、画像認識の利用が可能
• 非技術者が、テストシナリオの作成・更新を行える
  • テストシナリオの作成に、コーディングが不要
• モバイルアプリのCI/CDパイプラインに組み込める
  • ウェルスナビでCI/CDに利用している、Bitriseのステップに組み込みが可能
• 学習コストが低い
  • ウェルスナビでWebサイトのE2Eテストに、Autifyを利用していた経験から、同じUI/UXで操作できると判断

ロードマップ

モバイルアプリのテスト自動化ツール採択後、以下の時系列の通り、リグレッションテストを一部「Autify for Mobile」に置き換えました。

モバイルアプリのテスト自動化による結果

モバイルアプリテスト自動化の成果

ウェルスナビでは、Autify for Mobile導入により、以下の成果を得られました。

• リグレッションテストにかかる工数の削減
  • 人が手動で実施する工数を以下の通り削減できた
    • iOS: 48.4%
    • Android: 38.8%
• テストケースのカバー範囲の拡大
  • 手動のリグレッションテストでは、工数の関係で業務の最短経路である正常系一通りのみを実施していたが、Autify for Mobileの導入によってカバー出来る正常系のケースを拡大でき、デグレの発生検知の範囲を拡大できた
• 既存不具合の検出
  • 上記のテストケースのカバー範囲の拡大に伴い、Autify for Mobile導入前から潜在していた不具合をテストシナリオ作成の中で検知できた

テストの一例

新たに発生した課題

一方で、Autify for Mobile導入により、新たに以下の課題が発生しました。 (2024-03-01時点)

• flaky testが発生する
  • ブラウザに遷移するテストシナリオが不安定(iOS限定)
    • iOSのモバイルアプリでブラウザに遷移するタップ操作を行うと、稀にタップ操作が長押し状態となり、意図しないプレビュー画面が表示される
  • iOSのキーボード入力でテストシナリオが不安定(iOS限定)
    • iOSのモバイルアプリにおいて、OS標準のキーボード入力操作で稀に入力に失敗する
• テストシナリオすべてをAutify for Mobileに置き換えできていない
  • テスト自動化できないテストシナリオの存在
    • Autify for Webにある、js実行機能やランダムメール生成機能がなく、Autify for Mobile上で作成できていないテストシナリオがある
    • 現在は、手動で実施するテストシナリオと自動で実施するテストシナリオに分割して、リグレッションテストを実行している
• テスト実行したいOSバージョンが無い場合がある
  • 新しくリリース予定のOSのβ版確認が手動
    • OSのβ版が公開された際に、Autify for Mobile上にβ版のOSがないため、手動でテスト実行している

さいごに

ウェルスナビでは、モバイルアプリの改修によるデグレの検知としてリグレッションテストを行っていますが、テスターさんにとっては同じテストシナリオを短期間で複数回実行することに負担がありました。
今回、ウェルスナビでモバイルアプリのテスト自動化を実現できたことで、QAメンバーの工数の確保ができました。
結果として、要件定義や基本設計の段階から障害が発生しそうな箇所の特定や障害傾向から開発チームへのフィードバックなど、障害の予防や分析に焦点をあてられるようになりました。
今後は、新たに発生した課題を解決しモバイルアプリのテスト実行の安定化、既存のテストシナリオのさらなる充実によって、人にかかっている工数のさらなる削減とテスト実施の品質の向上を図っていきます。

---

📣 ウェルスナビは一緒に働く仲間を募集しています 📣

https://hrmos.co/pages/wealthnavi/jobs?category=1243739934161813504

---

著者プロフィール

木下智弘(きのした ともひろ)

2015年10月にウェルスナビに、エンジニアとして入社。
プライベートでは、Google Cloudを好んで利用しています。
Goのシンプルな考えが好きです。