メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の おれたま@AHA_oretama です。 私は普段、テスト自動化やCI / CD を主に行っています。
今回は、Appium×Android E2Eテストのテスト結果の見やすさを改善し、テスト結果を可視化することで気づきが生まれた話について、紹介していきたいと思います。
テスト結果の見やすさ、可視化の重要性について
ここでは、まずテスト結果の見やすさ、結果の可視化の重要性について触れておきたいと思います。
テスト結果とその可視化はどうあるべきか、それによってどのような効果があるか、を考えてみました。
- テスト結果は見やすくなければならない。
失敗したテスト結果が見やすくなければ、その原因の調査と対策に時間がかかってしまいます。
とくにUIテストは複数のレイヤをまたいで実行されるため、原因の特定は難しくなりがちです。
テストのメンテナンスコストが高いと、テストが失敗しても修正されにくくなり、テストが失敗されたまま放置される、という最悪のケースになってしまうこともあります。
逆にテスト結果が見やすく必要な情報がまとまっていれば、そのテスト結果を見るだけで原因をつかみ、対策を打つことができ、効率的にメンテナンスができるようになります。 -
変化に気づけるようにする必要がある。
テストは日々行うものであり、そこに変化があればそれをキャッチできるようにしておかなければなりません。
例えば、前回失敗していたテストのエラーと今回失敗したテストのエラーが違っていたとしましょう。その変化に気づき、何か新たな問題がないかを調査しなければなりません。
また、あるテストが前回に比べて１０倍時間がかかっていたとしたとした場合、前回との時間差分が見えるようになっていれば異常にすぐに気づき、対処することができるはずです。 -
改善へのインスペクションを与えるべき。
とくにE2Eテストを日々メンテナンスしていると、さまざまな問題が実は隠されていることが多いです。
例えば、テスト時間が日に日に増大している、ある端末で実行するとテストが不安定になりやすい、などです。
これらの情報が可視化されていれば、次にしなければならない改善タスクを明確にすることができます。
いま使っているテストレポートの課題
メルカリのAndroid E2Eテストでは、RSpec HTML Reporterを用いてテスト結果を出力しています。
詳しくは過去のブログをご覧ください。
RSpec HTML Reporterは簡単にセットアップ＆利用することができ、スタックトレースに加えてスクリーンショット、スクリーンレコードも表示して、リッチなUIでテスト結果をレポートしてくれる優れたツールです。
しかしながら、E2Eテストのメンテナンスを行っている中で、RSpec HTML Reporterでは解決できない、いくつかの課題が見えてきました。
| どうあるべきか | RSpec HTML Reporterでの課題 |
|---|---|
| テスト結果は見やすくなければならない。 | ・テストケース数、テスト時間が増えたため、テストの並列実行を行っているが、並列化した分だけレポートも分かれてしまい、まとめてテスト結果を見ることができない。 ・スクリーンショット、スクリーンレコード以外のアタッチメントを追加することができず、ページソースやログを見ることができない。 |
| 変化に気づけるようにする必要がある。 | いつから失敗しているのか、過去に同様の原因で失敗していないかなど、過去のテスト結果と比較することが困難。 |
| 改善へのインスペクションを与えるべき。 | 過去からのトレンドや定量データを見ることができない。 |
上記の課題の解決として、主に２つのツールを導入しました。
Allure Framework
Allure Frameworkは、複数言語をサポートしているテストレポートツールであり、カテゴリー分けの機能やトレンド、タイムラインなどのリッチなUIを持つテストレポートが出力されます。
Appiumと同じく複数言語をサポートしているため、Appiumとの相性は非常に良いと思います。
上記を用いることで、いくつかの問題を解決することができましたので、１つずつ紹介していきます。
並列化した分だけレポートも分かれてしまうことへの対処
RSpec HTML Reporterでは、テストの実行中にテストレポートのHTMLを作成します。
そのため、テストレポートは並列化して実行したジョブごとに作成されてしまい、その結果のHTMLをマージすることは非常に困難です。
Allureではテスト結果はXMLに保存され、そのXMLに対してallure serveコマンドを実行することでテストレポートをブラウザ上で見ることができます。
並列化して実行したジョブごとにXMLが作成されますが、その後にXMLを集約してallure serveコマンドを実行することで全ての結果をまとめて見ることができます。
スクリーンショット、スクリーンレコード以外のアタッチメントを追加することができないことへの対処
ファイル名とファイルを指定してattach_fileメソッドでアタッチメントを追加することができます。
これにより、スクリーンショット、スクリーンレコード以外にもページソースやログなどをアタッチメントとして追加することができるようになりました。
以下のRuby、RSpecのコード例になります。
it "sample" do |e| ... e.attach_file "screenshot1", take_screenshot_as_file end
過去のテスト結果と比較できないことへの対処
Allureではデフォルトで過去の履歴を表示してくれます。
テスト結果のステータスも合わせて表示されているため、いつから失敗しているのかがすぐに分かります。
この過去の履歴はリンクになっていて、過去のテスト結果をすぐに見ることができます。
他の改善点
上記の課題以外にも、細かい話ですが、いくつか改善することができました。
テストのタイムラインが見える
タイムラインを表示できるようになったことで、どの端末でどのテストをどれぐらい実行していたのか、以下のグラフで確認できるようになりました。
トレンドも表示できる
Allureでは、今回と過去何回かの結果からトレンドを表示する機能があり、ひと目で概要を掴むことができます。
Looker
上記のAllureの導入で、過去の履歴が見えるようになりましたが、Allureでは過去数回の履歴しか見ることができません。
またそのグラフはAllureが提供しているものしか見ることができず、それ以外のデータについては可視化することができません。
過去からのトレンドや定量データを見ることができない、という課題に対し、テストの結果をDBに半永久的に保存して、トレンドや情報を把握できるようにLookerで可視化しました。
メルカリでは全社的にVisualizationツールとして、Lookerを導入しています。
Lookerについて詳しく知りたい方は以下のブログを参照してください。
LookerというVisualizationツールを使うメリットとしては、自由にクエリを組み立てることができるため、自分の好きなデータを表示することができることです。
その反面、デメリットとしてはすべてのクエリを組み立てる必要が出てきます。
アーキテクチャは以下のようになります。
毎回のテスト結果をAPI経由でCloudSQLに保存します。その保存したテスト結果をLookerで表示するというシンプルな構成になります。
このようにして、作成されたダッシュボードが以下になります。
テストケース数の推移や端末ごとのテスト成功率、テスト時間などの自分にとって必要なデータを可視化することができました。
また、一時的に見たいデータがあったときに、ダッシュボード化せずともLookerの機能をそのまま使い、過去のデータを表示することができます。
このように、DBとLookerを使って、過去からのトレンドや定量データを見ることができない、という課題に対して対処しました。
生まれた気づき
ここでは、テスト結果を可視化したことによって生まれた気づきについてお話したいと思います。
いままでは、どのテストが遅いか、ということは、感覚的に「なんとなく」しか分かっていませんでした。この可視化によってテストケースの各時間が見えるようになると、「このテストが一番遅いのか〜、なんとかしないといけないなぁ」とか「１０分以上かかっているの！？最低でも５分以内に抑えたいね」という話が生まれました。
可視化から気づき、気づきから改善の話が生まれるという、非常によいフィードバックが生まれました。実際にはまだ改善するところまでできていませんが、今後、改善まで実施していきたいと思います。
課題
この可視化の中で一番足りないものはテスト失敗の原因データです。
失敗したテストケースについて、原因の調査とその対応は行っているのですが、その原因をデータとして保存しているわけでありません。
原因のデータを保存することで、環境起因なのか、それともアプリ側のバグなのか、UIテスト特有の不安定性によるものなのか、などのテストが失敗した原因のトレンドを可視化することができます。
またアプリ側のバグを取得しつづければ、それを元にE2Eテストの有用性を証明することもできます。
このように原因の分析データは非常に有効なデータなので、すぐに取得して保存できるようにしたい、と考えています。
また、このような可視化されたデータについては、定期的に見てもらうようにしていかなければなりません。
そのための布教や仕組みづくりは今後も続けていかなければなりません。
終わりに
このようにして、テスト結果の見やすさを改善し、テスト結果の可視化を行って日々データを見れるようになりました。
まだ課題は残されていますし、やらなければならないことはまだまだ多いですが、このテスト結果の見やすさの改善により、メンテナンスコストが少し楽になりました。またこの可視化によって、いくつかの気づきが生まれてたのは事実です。
この気付きが改善へとつながり、その改善した結果が可視化され、また気づきが生まれる、という正のフィードバックを今後はチームでうまく回していければ、と思っています。
