画像を使ったテストでリリースサイクルをあげる

こんにちは、MisocaでAndroidアプリを作っている @k0matatsu です。

MisocaのAndroidアプリではリリース前に通常10営業日のテスト期間を設けています。
おおよそ1ヶ月に1回リリースを行っているため、開発期間の半分がテストに費やされていることになり機能追加にさける時間が圧迫されています。

そこで、品質を落とさずにテスト期間を圧縮するために画像のdiffによるテストを導入しました。
これにより表示を確認するテストケースは大幅に削減できます。

spoonを使ったスクリーンショットの取得

f:id:komatatsu:20190624193113j:plain

画像のdiffによるテストを導入するためにspoonというソフトウェアを使いました。
これはAndroidの開発を行っている人にはポピュラーな選択肢だと思います。
この記事では詳しい使い方などは説明しませんが、ネットにたくさんの知見がありますので興味を持たれた方は調べてみてください。

espressoやUI Automatorを使って画面表示や遷移を行い撮影したい状況を作り、spoonを使ってキャプチャするという方法でスクリーンショットを撮影しています。
撮影されたスクリーンショットはdiffの比較がしやすいようにスクリプトでまとめています。
本当はreg-suitなどを使って見やすくしたかったのですが、最初から完璧をめざしているとなかなか導入できないので、ひとまずgithub上で見比べることができることをゴールとしました。

ほかにも次の点については導入段階では対応しない判断を行いました。

  • 通信処理のモック化
    • これはチャレンジしていたのですがハマってしまったので諦めました
    • スクリーンショットの撮影は日に何度も行うわけではないので決まった環境で実施する運用でカバーするものとします*1
  • 画面表示のバリエーション網羅
    • 税の設定や金額で多岐にわたるバリエーションがあるため断念しました
    • 徐々に範囲を拡大したいと思っています

一方で、テストの安定性については妥協せず進めました。
UIの絡むテストだと表示の待ち合わせなどで成功率がさがりがちですが、偶発的に失敗するテストは信頼感を損ないます。
テストが信頼できないと人間による確認の手間が発生してしまい、メリットが薄まってしまうのでこの点はこだわりました。
今はテストコードが原因で偶発的に失敗するようなテストはリポジトリにありません。

恩恵について

この画像のdiffによるテストが適用されたバージョンはまだ開発中なので具体的に何日短縮できたのかはまだ明らかになっていませんが、多くのテストケースが削減できそうなので期待を寄せています。
テスト工数の削減はリリースサイクルをあげるだけでなく、人間でないと判断が難しい作業にリソースを集中させられるメリットがあります。
UIテストにおいてテストケースのメンテナンスコストがよく問題視されますが、毎バージョン変更が入るような画面はほとんど無いはずです。
テストが自動化されることで些細な変更でも「変更した部分だけ確認しよう」ではなく、すべてのテストケースを確認しやすくなります。
このような変化が品質の底上げにつながると信じています。

MisocaのAndroidアプリもカバレッジはまだまだ低いですが、効果の高い部分から地道に自動テストの範囲を拡大しています。
私はこういった基盤的な作業が好きなのですがMisocaにはAndroidエンジニアは私しかおらず、普段はサーバーサイドエンジニアに手伝って貰っています。
たしかに品質も大事なのですが、フリーランスの商取引における課題はまだまだ山積しています。
これらの課題を解決し、フリーランスの方々が安心して自分の業務に集中できる環境を構築すべく新たな機能の設計開発にももっともっと取り組みたいと思っています。

Misocaでは私の背を守りバリバリと価値を形にしてくれるAndroidエンジニアを募集しています。

recruit.misoca.jp

Twitterなどでお声がけいただければ普段の様子などお話できますのでぜひご気軽ににお声がけください。

追記: テスト対象とした画面について

Twitterにて対象とする画面について質問がきたのでこちらに追記します 。

画像のdiffによるテストの導入は普段の作業の合間に少しずつ進めていました。
この作業に割ける時間は少なかったので、テストを書いてもすぐ修正することにならないように、変更頻度の低そうな設定画面のキャプチャからはじめました。
次いで全画面のファーストビューのスクリーンショットを撮ろうとしているのが今の状態です。
今後は再現させるのが難しいエラーの表示から優先的に範囲を広げていこうと思っています。
これは元の目的がテスト期間の削減なので、簡単にテストできる正常系よりも再現手順の面倒な準正常系を自動化したほうがテスターの負荷がさげられると考えているためです。

*1:ユニットテストは既にモック化されているのでこの判断になりました