はじめに
こんにちは、モノタロウのスマートフォンアプリチームに所属している坂江です。
スマートフォンアプリを開発する際、UIテストってとても大変ですよね。
- UIの開発や対象OSに比例して増える確認項目
- マニュアル作業での確認により膨れ上がるテスト工数
- etc.
UIテストが重要であることは分かっているのですが、テストを重要視するあまり工数が膨れ、肝心な開発や新しい取り組みへの時間がなかなか確保できなくなってしまいとても困っていました。
本記事では、モノタロウのスマートフォンアプリ開発において「膨大なテストをいかに効率化し、リリースサイクルを向上させていったか」をご紹介します。
ここでのテストとは主にUIテストのことを指しています。UIテストは実ユーザの操作を行うことを目的としており、画面を操作してテストケースを確認していくため、テストの中でも特に工数のかかる作業になります。非常に重要である一方で、限られた時間の中で新機能や改修を高い頻度でリリースしていくためには、開発とテストをいかに両立していくかが非常に重要になってきます。今回は課題に対して、UIテストの自動化と、運用面からの改善という二つの側面からアプローチしています。単にUIテストを自動化するだけでなく、運用面での改善の重要性も読み取っていただき、効率化を目指す第一歩として参考になれば幸いです。
スマートフォンアプリチームについて
モノタロウのスマートフォンアプリチームがメインで担当しているのはNativeアプリ側の実装になります。Nativeアプリとは、App storeやGoogle Play経由でダウンロードできるiOS/Androidアプリのことで、ここではSwiftやKotlinなどのNative言語で作成されたアプリのことを指します。Nativeアプリの機能の一つとして、HTMLコンテンツをNativeアプリ内に表示する仕組みのWebViewがあります。モノタロウはサービスが大規模であるが故に全てをNativeで実装することは困難です。そのため、WebViewも採用しています。モノタロウのNativeアプリはWebViewが占める割合も多く、必要に応じてWebの開発も行います。
まとめると、スマートフォンアプリチームはメインはNative側の実装からリリースまで、必要に応じてWebの開発も担当すると言った具合です。
次に、スマートフォンアプリチームの開発からリリースまでの流れを説明します。一部省略している部分はありますが、大まかには図1のような流れになります。
- 各メンバーにチケットをアサインして、それに基づいて開発
- リリース用のブランチを作って結合テストを実施（ここでの結合テストにはUIテストも含まれており、画面を操作し挙動を確認していきます）
- Apple StoreやGoogle Playといったストアへの申請
- 最終確認のリリース前テストを実施
- ストアへ公開
- 各種レポートを随時モニタリング
リリースサイクルにおける課題
このようなリリースまでの流れの中で、いくつかの課題が発生していました。
最も大きな課題が、「結合テストに時間がかかる」というものです。ここでの結合テストではUIテストも含まれているため、画面を操作し挙動に問題がないかを一つ一つマニュアル作業で確認していきます。前提としてお客様がBtoBのため、ユーザ側でのアプリのアップデート制限されているケースもあり、リリース時の品質確保は重要です。その品質確保のためのリグレッションテストが多く、そのため、一定期間の機能追加を3ヶ月毎にリリースするというリリースサイクルの制約がありました。結果的に一つの機能追加において、開発が2週間だっとしても最遅3ヶ月かかるという状態になっていました。
これほど多くの時間を要していた原因としては、まず、テストケースの多さがありました。テストケースは約3000ケースあり、それらをモノタロウアプリをインストール可能な全てのOS（当時iOS5つ、Android6つ）で実施していたため、膨大なテストケースをこなすことになり、かなりの時間を要してしまいました。そして、これらのテストケースを都度マニュアル作業で実施していたため、さらに時間を要してしまっていました。
解決に向けた取り組み①：自動テスト導入
この課題を解決するために、まず「自動テストの導入」に取り組んでいくようにしました。
UIテストの自動化については、スマートフォンアプリチームで過去に導入を試みましたが、当初のゴールまで辿り着けなかったという過去がありました。
なぜ過去の試みが途中で挫折したかについてですが、まずその原因の一つに、「テストケースを全てUI自動テストでカバーしようとしていた」ということがあります。既存のテストケース全てを実装しようとしていたため、運用まで到達できませんでした。図2のような逆テストピラミッド状態だったのかもしれません。
また、テストコードをメンテナンスする運用が定まっておらず、日々UIはどんどん変化していき、テストが壊れていったということも原因の一つでした。
このような過去の経緯があり、大半のテストケースが動かない状態になっていました。
幸いにも過去の試みの一部は使える状態であったため、それらを再利用することにして、iOSは「XCUITest*1」、Androidは「Espresso*2」を使って、UI自動テストを実装していくことにしました。
実装していくにあたっては、以下の2点を意識して進めていくことを心がけました。
- 範囲を絞って小さく始める
- できたものから順次使っていく
範囲を絞るにあたって、以下のように各フェーズを設定しました。
- 第1フェーズ：コンバージョンに絡む必須テストケース
- 第2フェーズ：コンバージョンに絡む全てのテストケース
- 第3フェーズ：主要ページのテストケース
これらのフェーズを順番に実装していき、各フェーズの実装が完了次第、順次使っていくというように進めていきました。
解決に向けた取り組み②：運用面での見直し
UI自動テストは実装できましたが、まだ課題はあります。それは「UI自動テストだけではカバー範囲が狭い」という点です。
実装するテストケースを絞ったため当然自動テストでカバーできる範囲は狭くなります。また、自動化できていないテストケースについてはマニュアルでのテストが必要になってきます。残っているテストケースをリリースの都度マニュアルで実施していては時間がいくらあっても足りません。そこで、今までの全テストケースをテストする運用を見直し、バージョンアップごとのテスト範囲を整理することにしました。
それぞれのバージョンアップ時にどのようなテストを実施するのかをまとめたものが表1になります。
さらに、テスト対象のOSについても見直すことにしました。
ユーザ数や売上などを考慮して、動作確認の対象に含めるかを検討し、テスト対象をiOSについてはiOS12以上（検討前はiOS9以上）、AndroidについてはAndroid6以上（検討前はAndroid5以上）に見直しました。
こうすることで、テストを実施するOS数を減らし、テスト工数を削減することができました。
よくなった点
これらの取り組みを通して、テスト工数を約75%削減することができました。まだまだ改善の余地はありますが、取り組みの第一歩目としてはうまくもっていくことができました。
そして、テスト工数の削減に伴い、エンジニアとしてやりたいこと（開発など）に当てられる時間がかなり増えたと実感しています。
また、今まで大変な思いをして実施していたマニュアルのUIテストを自動化することができたというのはチームとして工数が削減できたこと以上のインパクトがありました。チーム内ではこれを機に、様々なものを自動化していこうという動きが強まっています。
学び
テスト工数を大幅に削減するという目標に対して、テストを自動化することだけにフォーカスしていた場合、ゴールには到達できなかったかもしれません。今回のように、どのバージョンアップの時にどのようなテストを対象とするのかといったテストの運用自体を見直すことも、テストの工数の削減に大きく貢献しました。つまり「開発と運用の両方の視点から改善する」ということが重要であると学びました。エンジニアとしてはどうしても開発にフォーカスし、それによって解決策を提示したくなることが多いかと思います。しかしそのような時でも、一歩引いていつもとは違う視点でもう一度考えてみると、思わぬ打開策が見えてくることがあります。
また「最小限から始める」というのも重要なポイントでした。今回は実装するテストケースを絞り開発対象を小さく始めることで、確実に導入まで持っていくことができました。始めから全テストケースをUI自動テストでカバーしようとしていたら、過去と同様に破綻していたかもしれません。この「最小限から始める」というのは今回の件に限った話ではなく、様々な場面で応用できることではないかと思います。
おわりに
モノタロウのスマートフォンアプリでは、テスト工数の課題について、UIテストの自動化と、運用面を見直すことで改善しました。
本記事ではUIテストにフォーカスしていますが、単体テストについてもより充実させ、自動化をより推進していきたいと考えています。今後も、今回の学びを活かして取り組んでいきたいです。
モノタロウでは随時エンジニアの採用募集をしております。この記事に興味を持っていただけた方や、モノタロウのエンジニアと話してみたい！という方はカジュアル面談フォームからご応募お待ちしております。
