こんにちは。メルカリでQA-SETチームのマネージャ兼自動化エンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。
先日開催された Mercari Tech Conf 2017 において、自動テストのデモ展示を担当させていただきました。当日は多くの方にお越しいただき、スマホアプリの自動化への関心は大きいのかなぁと感じております。
この記事では、テスト自動化についてよく質問されたことをまとめてみたいと思います。どの現場も同じように悩んでおり、試行錯誤している点も似ていたので、ノウハウとして残れば幸いです。
Q. どんな技術をつかってアプリの自動化をしているのですか？
A: AndroidはAppium（Ruby) を使っています。
Gemが豊富なので以下のようなGemを使って実装を効率化しています。
# Gemfile sample gem 'appium_kit', git: 'git@github.com:xxxxxxx/appium_kit.git' gem 'mercari_kit', git: 'git@github.com:xxxxxxx/mercari-ruby-kit.git' gem 'rspec_html_formatter2', git: 'https://github.com/vbanthia/rspec_html_formatter2' gem 'rake', '~> 12.0' gem 'rspec', '~> 3.5' gem 'rspec-expectations', '~> 3.6' gem 'rspec-retry', '~> 0.5.4' gem 'site_prism', '~> 2.9' gem 'rest-client', '~> 2.0.1' gem 'settingslogic', '~> 2.0' gem 'net-ssh', '~> 4.1.0' gem 'net-ssh-gateway', '~> 2.0.0' gem 'mysql2', '~> 0.4.6' gem 'rspec_junit_formatter', '~> 0.2.3' gem 'google-cloud-storage'
appium_kit は、社内で作ったAppiumを使いやすくするライブラリです。 mercari_kit は社内APIのRubyクライアントで、主にテストデータ生成に使っていますが、「出品者を作る ＞ 出品する ＞ 購入者を作る ＞ 購入する」といった準備をAPI経由で行っているので、APIのシナリオテストにもなっている感じです。 site_prism というページオブジェクトを簡単利用できるライブラリを使うと以下のように、読みやすいコードになります。
# Page objectも簡単実装 require 'site_prism' module Pages class SignIn < SitePrism::Page element :back_button, :id, 'back_button' element :title, :id, 'title' element :facebook_button, :id, 'facebook_button' element :google_button, :id, 'google_button' element :email_button, :id, 'mail_button' end end
# specも読みやすくなるので、失敗した場所も特定しやすくなります sign_in = Pages::SignIn::new sign_in.wait_for_email_button sign_in.email_button.click
テストフレームワークは rspec です。 E2Eテストは不安定なので、落ちたケースだけリトライするために rspec-retry を使っています。自動で作られたapkを保存する場所として google-cloud-storage を使っており、そこからビルド番号指定だけでE2Eテスト実行できる環境になっています。
iOS側はXCUITestを利用しており、iOS Test Night 等で @tadashi0713 から継続的に発表させていただいていおり、以下のスライドがわかりやすいと思います。
E2Eテスト実行環境は Jenkins ＋ Mac mini を利用しています。ビルド環境は社内だと BITRISE （以下の資料を参照のこと） がスタンダードになってきたので、そこから自動でキックされる仕組みに仕上げていくかもしれません。
Q. テスト端末は実機だけですか？ AWS Device Farmなどを使う予定はありますか？
A: Android は実機6台を Mac mini につないで使っています。iOSはシミュレータです。
台数はサポート対象OSバージョンと、テストの実行時間次第で増やしたり減らしたりしています。
たとえば、現状、リグレッションテストとしてE2Eテストを活用していますが、ひとつのOSバージョンに対して、1時間ぐらいで終了するぐらいのボリュームです。さらに速く終わらせたくなったり、Android 8.x 対応もするようになると、台数を増やすつもりですが、いまのところこれぐらいの台数で運用に困っていない印象です。
iOS に関しては、もともと実機で動かしていましたが、 iOS だとシミュレータが安定しているので、シミュレータを使って実行するようになりました。並列実行数はCPUのパワーに依存するようで、今は Mac mini を使っていますが、今度は Mac Pro を試すところです。iOS のシミュレータだとカメラが動かせないのでそういったテストだけ実機というすみわけになりそうです。
AWS Device Farm は以前利用していましたが、動作が遅かったので断念しました。将来的に性能が上がって、ローカルで動かすような感覚で使えるようになれば、そちらへの移設も検討したいと思っています。
あとは、Android に関しては STF の利用も検討中です。管理する端末も100台を超えてきたので、もうちょっと効率的にデバイス運用できないものか悩んでいるところです。
Q. どういったテストを自動 E2E テストにしていますか？
A: レグレッションテストから自動化しました。そこからAPIの結合テスト、API単体のブラックボックステストといったよりソフトウェア内部へ進んでいこうとしています。
ケース数でいうとAndroidだと 140件ぐらいだったものを60シナリオぐらいにまとめて運用しています。iOS もAndroid と同じシナリオ形式にそろえていますが、UIの違いがありえるので、まったく同じシナリオにしようとはしていません。
自動テストは費用対効果が気になりますが、気にせず Go Bold （大胆にやろう！）でやってみたところ、思ったよりは運用コストは低く、効果も大きいので満足している状況です。ここからカバレッジを上げるか？ それぞれのシナリオの質を上げるのか？ で悩んでいるところです。
ただ、最近だと、Webアプリに対してのスモークテスト（動作確認的なテスト）の自動化を試したところ、よく使われるいいテストとして運用されています。これはつまり、基本的な機能のチェックが自動化されるだけでも、QAエンジニアには十分ハッピーということかもしれません。
よって、カバレッジは薄く狭くではじめて、利用状況を見つつ広げていくのがよさそうだなーと感じています。
Q. 自動テストって効果大きいですか？
A: 致命的なバグが見つかったことは、今のところありません。
よく聞かれる質問でしたが、よく見つかるバグとしては「遷移先が元の画面だったけど、ホーム画面に戻ってしまっている」といった、「大きな影響はないかもしれないけどお客様にとってちょっと不便になってしまうバグ」です。
それぐらいのバグしか見つからないなら自動化しなくとも・・・という意見もありますが、個人的には自動と手動で以下のようなすみわけがあっても良いのではないかと考えはじめました。
- マニュアルテストでは、新機能や修正箇所を重点的に探索テストする
- 探索テストに集中できるように、それ以外の機能がちゃんと動いていることを、自動テストで何回も確認できるようにする
例えば、アプリの設定画面は、そう多く操作される画面ではないかもしれません。ただ、その機能が使えなくなるのは不便なので、そういう点を自動チェックすれば、QAエンジニアが安心して新機能のテストに集中できるのではないでしょうか。たとえばこんな感じ。
- よく使われる機能 => メルカリだと出品や購入。手動メイン。ただ、正常系シナリオだけ自動化しても良さそう
- たまに使われる機能 => 設定画面などは、自動テスト化しておくと安心が増える
Q. SETは自動テストの実装とメンテナンスが担当なのですか？
A: 今はそうなっています。
本来は、コードを書いた人間がテストコードも書くべきだと思いますが、理想的な状況になるまで待てないので、今はテストコードの実装と運用をSETでやっています。
そして、導入も重要ですが、利用する人たちへの啓蒙も重要なので、最近だと、テストの実行やエラーの調査をQAエンジニアに担当してもらったり、「誰もがQA活動に参加する」形を取ろうとしています。
時間さえあれば、自動テストを作るのは簡単な時代です。問題はそれを使う側の心の持ちようなのかと思うようになりました。たとえば、「そういうのはSETでやってよ」みたいなやりとりになると、一気につまらない組織になってしまいますから。
おわりに
いろいろなご質問をいただきましたが、あるエンジニア様とお話させていただいたときに「結局最後にテストするだけだと品質上がらないですよねー」という話がでてきました。たしかにそのとおりです。
ただ、Mercari Tech Conf 2017 のデモブースが大盛況だったように、自動テストの実際の動作は華があってなかなかおもしろく、並列実行になると「未来だ！」とか「よさそう！」と感じてしまうものです。
「品質や生産性の向上」という永遠のお題に対して、自動化は試す価値のあるアクションだと思います。
PS・・・テストや自動化の話をカジュアルにできるようにFacebookグループ Agile Testing, Automation and QAの現場 を作ってみました。もしご興味があれば、ぜひ遊びにきてください！
