こんにちは、ソーシャル経済メディア「NewsPicks」の呉です。
この記事は NewsPicks アドベントカレンダー 2023 の17日目の記事です。
昨日は同じチームの西薗さんによる『QAエンジニアが「開発者になる」と自動テスト運用は上手くいく - Uzabase for Engineers』でした！
Qiita初ブログなので、まず簡単な自己紹介をさせてください。
普段はQAエンジニアをやっています。仕様のレビュー、テストの設計・管理・実行はもちろん、自動テストを書いたりもします。品質保証に関わる分野で幅広く関わっています。
今日の記事はiOSのE2Eテストの改善をテーマにした話です。
背景
NewsPicksではサーバーリリース時に自動E2Eテストを回しています。E2Eテストが失敗すると、テストの再実行を試み、あるいは手動テストで確認し、OKでしたらリリースを全適用するという流れになっています。そのため、E2Eテストの安定性と実行時間はリリースサイクルに大きく関わっています。
課題
約1年前、「Firebase Test Labで動かしていたiOSのE2Eテストを実機で動かして安定化させたら開発者の喜びが爆上がりした話」で紹介されましたが、リリースサイクルを高速化するために実機iPhoneでの安定したE2Eテストを実行する取り組みが行われました。その後、リリース時にFirebase Test Labと実機で並行してE2Eテストの実行が行われ、どちらかが成功するとリリースを全適用するという手順となりました。
※E2Eテストの具体的な仕組みについては上記の記事にて詳しく紹介されておりますので、ご興味があれば是非あわせて読んでみてください。
平均的なテスト実行時間について実機は16分、Firebase Test Labは20分がかかります。確かに実機のほうが早く完了しています。
しかし、WebのE2Eテストの平均実行時間は現在7分となっており、そちらと比較すると倍以上かかっています。
さらに、もしテストが失敗すると、再実行してさらに（最低でも）16分が必要ということになります。
（テスト失敗時はテストを最初から再度実行するという直列の状態仕組みになっていました）
開発組織としては、より効率的に品質を担保するためにはさらにE2Eテストのケースを増やしたいという意向があります。
しかし、現状でもWebのE2Eテストと比較すると実行時間が長く、ケースを増やすとさらに実行時間が増えてしまうという大きな課題に直面していました。
取り組み
E2Eテストのテストケースを増やしてもリリースサイクルに影響しないには、まず実行時間を短縮しなければいけない。そのために、テストファイルの分割を考えました。今まで直列で動いていたE2Eのテストケースを依存関係のない3つのグループに分け、並列でFirebase Test Labで動かす仕組みに変えてしてみました。分割したE2Eテストは全て同じタイミングでスタートするため、理論上早く終わると考えられます。
実行時間の短縮と安定性が確認されるまでには実機で直列で動くE2Eテストもそのまま残して、分割したE2Eテストとの比較検証をしました。
検証結果
分割したE2Eテストが実際にサーバーリリース時に動くように適用されてすぐ、社内から「爆速！」「早い！」という嬉しい声が集まりました。
その後約1ヶ月間、障害やテストケースの不備が原因で不安定となった実行結果を除いて、計30回の実行結果を集計しました。
以下の表が分割されたA、B、Cと分割されていない実機のE2Eテスト、それぞれの所要時間と成功率をまとめた結果です。
| テストグループ | 実行終了までの平均所用時間 | 成功率 |
|---|---|---|
| A | 8分36秒 | 96.7% |
| B | 10分22秒 | 96.7% |
| C | ９分30秒 | 100% |
| ALL(実機) | 16分50秒 | 66.7% |
実機と比べると、分割されたケースの方が６分以上も早く終わっていることが分かります。また、テストが失敗した場合の再実行もより早く終わります。
さらに、分割して実行することによって、E2Eテストの成功率が大幅に上がったことが分かりました。直列での実行より、ある程度依存関係のないグループに小分けしたほうが安定性が上がります。
その後もしばらくE2Eテストの実行結果を監視していましたが、やはりTest Labでの並列実行が実機の直列実行に比べて
- 成功率が高い
- テスト時間が短い
- 再実行が早い
という点に変わりがなかったので、iOSアプリの実機E2Eテストを廃止しました。
サーバールームに長く寂しく置かれていたiPhoneちゃん、遂に役目を終え、今度はテスト検証端末として生まれかわるのです。
おわりに
今回はアプリのE2Eテストの実行に関する結果検証について話しましたが、次回はQAエンジニアになってから勉強したテスト設計ネタを書きたいと思います。
明日は@kirihataによる「Brazeでメール配信の最適化」の話のようです。お楽しみに〜