Mercari Advent Calendar 2019も、この記事を入れてあと３個となりました。最後まで読んでくださいね。
23日目はAutomation&QAグループで、Webのテスト自動化を行っている@AHA_oretamaがお送りします。
今回はWebの自動テストについて、この１年やってきたことを振り返ってみようかと思います。
Webのリアーキテクチャ
現在、Webではリアーキテクチャを進めています。
進め方としては既存のモノリシックなWebアプリケーションを残したまま、パス（例えばトップ /jp/ や検索ページ /jp/search/ ）ごとに新しいWebアプリケーションにマイグレーションする方法をとっています。
影響範囲を小さくしつつその範囲の中でチャレンジが行えることがこの方法の利点です。
詳しくは去年のMercari Tech Confの資料をご覧ください。
Webのテスト戦略
上記のようにパスごとのマイグレーションを行っていく場合、既存のモノリシックなWebアプリケーションとリアーキテクチャされた新アプリケーションがパスごとに切り替わるため、全体としてのWebアプリケーション品質を担保することが重要になってきます。
これはテストピラミッドのUnitテスト層ではカバーしきれない領域です。そこで、私達はテストピラミッドのUIテスト層にあたる、E2E（エンドツーエンド）テストを積極的に導入していくことに決めました。
ここでテストピラミッドの解説をしておきます。
https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
テストピラミッドは自動テストの比率を表している図であり、このような比率になるように構築していくと、効率のよいテストを行えるようになります。
自動テストの特徴として、上の層にいくほど忠実度があがる代わりに実行時間、メンテナンスコストが増えていきますので、UIテスト層は少なくするのがよいと言われています。
Unitテストが少なく、UIテストが多くある状態は逆テストピラミッドと呼ばれ、一般的にはアンチパターンと認識されています。
今回、私達のWebアプリケーションでのテスト戦略は、E2Eを積極的に導入していくことでこの逆ピラミッドに近づいていってしまいます。その一番の理由は、残念ながら既存のモノリシックなWebアプリケーションにはUnitテストがあまり存在しないことにあります。
幸いなことにリアーキテクチャされた新アプリケーションについてはUnitテストを当たり前に実施するチームの文化ができているため、パスごとのマイグレーションが行われるごとに相対的にUnitテストの比率は増えていき、逆ピラミッド型から正しいテストピラミッドへ近づいていくことになります。
逆ピラミッド型はアンチパターンと呼ばれますが、一時的に逆テストピラミッドを採用することは決して悪いことではなく、今回は正しいテストピラミッドへの過渡期として戦略的に逆テストピラミッド型を採用することにしました。
E2Eテストで目指しているところ
AutomationチームはQAと同じ組織であり、今まで作成してきたAndroidやiOSのE2EテストのメインターゲットはQAエンジニアを対象としていました。そのため、いかにQAの工数を削減することができるかにフォーカスすることが多くなっていました。
しかしながら、E2EテストをQAフェーズやリリース前に実施するよりも開発フェーズで実施するほうが品質、開発生産性への寄与が大きく、今回のWebのE2Eテストでは、開発フローにE2Eテストを組み込むことを目標にしてきました。
E2Eテストを開発フローに組み込む場合、E2Eテストのフィードバックを受けるのはデベロッパーであり、
最終的にはデベロッパーが自らE2Eテストの作成まで行ってくれることを目指してきました。
詳しくは、私が発表した資料がありますのでそちらをご覧ください。
この１年でやってきたこと
この１年は主に３つのフェーズに分けることができます。
- 構築フェーズ
- 拡大フェーズ
- 導入フェーズ
それぞれ詳しく紹介していきます。
構築フェーズ
最初の約３ヶ月はテスト戦略作りから始まりました。先程述べたようにテスト戦略としてE2Eテストを積極的に導入するように決めてから、テストケース、テストスクリプト作成、CI環境の導入などを行ってきました。
安定してE2Eテストを実行できるようにKubernetes上にSeleniumGridを構築もしました。
このフェーズではテスト戦略を決めるために何度も方針を議論したことを覚えています。
テスト戦略が決まってからは比較的スムーズに進みました。
拡大フェーズ
本来は構築したE2Eテストをプロジェクトに導入してフィードバックをもらいつつ改善していきたかったのですが、プロジェクトの事情でE2Eテストの導入は難しく、その間の約３ヶ月ほどE2Eテストを拡大していくフェーズとなりました。約３ヶ月ほどE2Eテストを拡大していくフェーズとなりました。
このフェーズでは、主にSafariやEdgeなどのマルチブラウザに対応していました。
マルチブラウザに対応する理由は、各ブラウザのアクセスが相当数あることと、W3CでWebDriverというブラウザの自動操作インタフェースが統一されているため比較的、効率的にマルチブラウザ対応できることにあります。
しかし自動操作のインタフェースが統一されていますが、細かいところで挙動に差があったり、またブラウザごとに動作するOSが異なるため専用の実行環境が必要だったりと、予想以上に苦労しました。
マルチブラウザについてはこれらの資料を見ることで、そのような苦労が見えるかと思います。
導入フェーズ
直近の何ヶ月間は、デベロッパーと同じようにプロジェクトの開発をしつつE2Eテストのメンテナンス、改善、布教を行なってきました。
主に活動してきたことをいくつかピックアップしてみます。
１つ目はUIテストのパイプラインへの導入です。
QAフェーズ中に手動でE2Eテストを実行していたものを、検証環境へのデプロイ時に自動的にE2Eテストが実行されるようにしました。
それ以外にもPull RequestごとにWebアプリケーションを起動し、Pull Request時にUIテスト（APIをモック化する想定で、純粋なE2Eテストではない）を実行して、より高速にフィードバックできるようにしました。
また本番環境への疎通確認テストとしてE2Eテストを利用もしています。
このようにフェーズごとにそのフェーズに適したテストが自動的に実行されるようにパイプラインを構築しました。
２つ目はプロジェクトチームへのE2Eテストの布教活動です。
ドキュメントの充実やチームへのプレゼンテーション、モブプロなどの活動をしてきました。
これは少し地道ですが、非常に重要な活動だと思っています。
この活動を通して、E2Eテストがどういったものか、どのフェーズで実行されているかをチームメンバに認識してもらい、E2Eテストをケアしてもらえるようになりました。
またチームメンバからもE2Eテストに対してPull Requestも来ました 🎉
この１年を振り返ってみて
この１年の活動で、良かったこと、うまく行っていないことなどいろいろありました。
１番良かったことは、目標としていた “E2Eテストを開発フローに組み込み、デベロッパーが自らE2Eテストの作成まで行ってくれる” ことを実現できつつあることにあります。
さきほど説明してきたような、UIテストのパイプラインへの導入やプロジェクトチームへのE2Eテストの布教活動など、いままでやってきた自分たちの活動が実を結んでいるので嬉しい限りです。
実現できつつあると言いましたが、まだまだ足りない部分もあります。
１つはまだチームの一部の人しかE2Eテストを修正したり実装したりできる状態にないことです。チーム全員がE2Eテストを書けるようになるのが理想だと考えています。
それ以外にも信頼性の向上があります。
同じテストを実行したとしても結果が毎回変わる（成功したり失敗したりする）などの信頼性がないテストはいずれ捨てられてしまいます。
E2Eテストは比較的信頼性が下がりやすいテストであり、これをいかに100%に持っていくかが重要なファクターになります。
リトライなどの対策はしていますが、それだけでは信頼性を十分担保できているわけではありません。
信頼性については継続して改善していく予定です。
反対に、うまく行っていないことではマルチブラウザ対応があります。
マルチブラウザ対応自体はしているのですが、その信頼性に問題があります。
E2Eテストが失敗したときの原因のほとんどは、Webアプリケーションのブラウザ差異ではなく、WebDriverのブラウザ差異によるものです。
つまり、ブラウザごとのWebアプリケーションを確認したいにも関わらず、ブラウザごとのWebDriverの動作を確認しているようになってしまっているのが現状です。
マルチブラウザのテストについては、今後どのような改善ができるか検討している段階です。
このように目標はだいぶ達成してきていますが、まだまだ課題はあるというのが現状です。
最後に
この１年、自分がやってきたことをまとめつつ、振り返ってみました。
１年やった自分の仕事を振り返ると、「もっとできたなぁ・・・」とか思ってしまうものですね。
振り返ることで「来年も頑張っていこう！」という気になれたのでよかったです。
Mercari Advent Calendar 2019もあと２記事になります。
明日（24日目）の執筆担当は @hatone です。引き続きお楽しみください。
