見出し画像

モバイルアプリのリグレッションテスト自動化にMaestroを導入しなかった4つの理由

yatt0825

Maestroとは？

Maestro is the simplest and most effective mobile UI testing framework.

https://maestro.mobile.dev/

Maestroは、テストツールの前身であるAppium、Espresso、UIAutomator、XCTestからの学習に基づいて構築された最新のモバイルアプリのテストフレームワークです。

今回は自社のiOS/Androidアプリのリリースの度に手作業で実施しているリグレッションテストの置き換えを目的としてMaestroの導入を検討しました。

まずMaestroを実際に利用してみて感じた良いところと微妙なところを紹介し、最後になぜ今回Maestroの導入を見送ったかの理由を説明します。

Maestroの良いところ

  • 簡単なテストコード

  • クロスプラットフォーム

  • Maestro Studio

簡単なテストコード

MaestroのテストコードはYAMLで記述します。さらにテスト対象が画面に表示されるまでsleepするといったような煩雑な処理もMaestroが勝手に面倒を見てくれるので自分で実装する必要がなく、テストの開発のしやすさとテストコードの可読性の高さが特徴です。

クロスプラットフォーム

iOS/Androidアプリをそれぞれをネイティブで開発している場合、テストコードもそれぞれで実装する必要があります。Maestroを利用すればiOS/Androidそれぞれ別の言語でテストを実装する必要がなく、どちらも同じ言語（YAML）同じAPIで実装することができます。これによりテストの開発と管理のコストを低減させることができます。

Maestro Studio

MaestroにはMaestro Studioというツールが内包されており、これを利用するとWebブラウザ上でアプリのUIをクリックしながらテストフローを構築することができます。そして構築したフローをYAMLとしてエクスポートできるため、直感的かつ簡単にテストを実装することができます。

Maestroの微妙なところ

  • iOS実機未対応

  • プラットフォーム依存のテストがカバーできない

iOS実機未対応

Maestro currently supports iOS Simulator builds (.app), AppStore distribution device builds (.ipa) are not currently supported.

https://maestro.mobile.dev/getting-started/build-and-install-your-app/ios

Maestroは現状iOSの実機でのテストに対応しておらず、シミュレーターでのみテストを実行できます。

プラットフォーム依存のテストがカバーできない

iOS/AndroidアプリのUIテストをそれぞれ別でMaestroで実装するなら問題ありませんが、開発コスト・管理コストの低減を目的に1つのテストコードで両プラットフォームをテストしたいというのは当然の欲求だと思います。しかしそうなるとどうしても下記のようなプラットフォーム依存のテストは実装できなくなってしまいます。

  • 端末のハードウェアを利用するテスト（例：カメラ）

  • 各プラットフォームのOS標準機能を利用するテスト（例：アルバムから写真選択）

  • 各プラットフォームで異なるOSSを利用して実装している機能のテスト（例：写真の編集ライブラリ）

採用を見送った理由

  • コスト対効果の問題

  • 自動化の限界

  • iOS実機の問題

  • ワンコードの維持管理の難しさ

コスト対効果の問題

弊社のアプリのリリース頻度は現状2週間に1回程度となっており、リグレッションテストも同じ頻度でしか実施しません。また手作業で実施しているリグレッションテストの工数も各プラットフォーム10分程度です。

今回とりあえずAndroidで一通りの自動テストが動作するまでに既に20時間弱を費やしており、これは手動テスト120回分の工数に相当します。さらに、今後UIが変更されるたびに自動テストの更新が必要となるため、MaestroによるUIテスト開発の工数がペイしないと判断しました。

自動化の限界

現状のリグレッションテストは大きく分類すると15項目あるのですが、その中で自動化できるものは8項目（50％）しかありませんでした。自動化できなかった項目の例としては、アカウント登録のメールアドレス認証やサブスクリプションの購入テスト、ユーザーの発話を利用した機能などで、これらは自動化させることができません。

iOS実機の問題

先にも紹介したとおり、MaestroはiOSの実機に対応していないため、リリースするビルドとは別にシミュレーター用のビルドを作成し、それに対してテストをすることなります。これは厳密に考えると、実際にリリースされるビルドのリグレッションテストにはなっていないという考え方もできます。

ワンコードの維持管理の難しさ

私は今回1つのテストで両プラットフォームに対応したかったため、プラットフォーム依存のテストをカバーすることができないことがネックになりました。

Appiumなどのように、テストコードは1つだけどテスト内でiOS/Androidなどの条件分岐をして別の実装をする、というようなことがMaestroではできません。そうなると必然的にiOS/AndroidそれぞれでMaestroのテストを実装・メンテナンスすることになり、コストが増大します。またテスト内容自体は同じため、多くのテストコードが重複してしまいます。Maestroの設計上、適切な粒度にテストフローを切り出すことで同じテストコードの重複を最大限避けることは可能かもしれませんが、そこにもまたコストがかかってしまいます。

まとめ

Maestroは、モバイルアプリのUIテストを自動化するための強力なツールですが、私たちのニーズには完全には合致しませんでした。特に、リグレッションテストの頻度や手動での工数が少ない現状では、自動テストに投資するコストがペイしないと判断しました。

今後もテストの効率化を目指し、適切なツールや方法を模索していく必要がありますが、現状では手動テストを継続しつつ、他の可能性も検討していく方針です。Maestroのようなツールが更に進化し、私たちの要件を満たすようになることを期待しています。

この記事が気に入ったらサポートをしてみませんか？