はじめに
こんにちは、SmartHRでQAエンジニアをしている machi です。
先日、E2Eの自動テストをプロダクトリポジトリに取り込んでビルドパイプラインに組み込むということにチャレンジしてみたので共有したいと思います。
SmartHRのE2E自動テスト
SmartHRでは、E2E自動テスト(ここではChromeなどのブラウザを介して行なうテストを指しています)をプロダクト自体のコードがあるリポジトリとは別の独立したリポジトリとして管理していました。E2E自動テストを単純にCIに組み込むと、自動テスト全体の実行時間が数倍〜数十倍に肥大化してしまう恐れがあるためです。 そこでE2E自動テストをステージング環境に対して定期的に実行し、失敗したらslackにアラート通知するという構成となっていました。 このE2E自動テスト用リポジトリは、単一のリポジトリの中でSmartHRのほぼすべてのプロダクトの自動テストが共存する構成になっています。
従業員サーベイの自動テストの状況
私は入社時から「従業員サーベイ」というプロダクトのQAを担当しています。 入社した直後から、「従業員サーベイ」でも他のプロダクトで行なっていたことと同様に、上述のE2E自動テスト用リポジトリへ自動テストを継続的に追加してきました。 しかし、これを続けていく中で大きく2つの問題が顕在化してきました。
まず1つ目の問題は、E2E自動テストの実行がステージング環境に対する定期実行になっているため、リリースまでの間にE2E自動テストがpassすることを保証できない点です。 大抵はステージング環境による定期実行で気づけるのですが、定期実行直後に変更がマージされたものや、hotfixにより即座に本番リリースする必要がある際には、E2E自動テストがpassしていることの確証が得られないため、不安が残り続けるという問題がありました。
2つ目の問題は、リポジトリが分かれていることによってコードの変更にあわせたE2E自動テストの追従がうまくいかないということです。 E2E自動テストはPull Requestのコードベースに対して実行されないため、E2E自動テストの変更が漏れたままコードがマージされ、あとからアラート通知で漏れていたことに気づくということが多発しました。このコードの修正は、開発チーム全員でやろうという合意はしているものの、E2E自動テストのリポジトリはもともと私がメンテナンスしていることもあり、大半は私が一番最初にテストの失敗に気づき修正を行なう、という事実上属人化した状態が発生していました。
開発チームとしては特に1つ目の「リリースまでの間にテストがpassすることを保証できない」という点は致命的で、E2E自動テストで本来気付けるはずの問題に気づけずインシデントを発生させてしまうのではないか、という不安を抱えていました。 これらを解決するには、E2E自動テストを独立したリポジトリからプロダクトリポジトリに移し、ビルドパイプラインの中にE2E自動テストを組み込んでしまえばよさそうです。
そこで、E2E自動テストをプロダクトリポジトリに取り込んで本当に問題がないか、広い視点でメリット・デメリットを検討することにしました。
プロダクトリポジトリに取り込むメリット・デメリット
以下が実際に挙がったメリットとデメリットです。
プロダクトリポジトリのデメリットとして「自動テスト未経験者はチャレンジしにくい」という項目が上がりましたが、すでに1年近くE2E自動テストに開発チームで取り組んできたこともあり、既に解消されている状況でした。 残る問題は「ビルド時間が大幅に増える可能性がある」という点で、ここを許容できるかどうかについて開発チームで議論をしました。
ビルド時間増 vs 他のメリット
E2E自動テストは不安定になることも多く、実行時間も単体テストなどに比べると大幅に増えてしまいます。これをビルドパイプラインに組み込むとなれば、当然ビルド時間も増加します。 ただし、テストを安定させるためにコードを修正したり、実行速度を上げるために並列化するなどで影響を軽減させることは可能です。
一方でビルドパイプラインに組み込むことでPull Request単位でテストが実行されるため、万が一壊れてしまった際には素早くフィードバックを得られます。 つまり、修正コストが小さく済みます。 また、仮に新機能実装やバグ修正・リファクタリングなどで既存テストに影響が出る変更を加えた場合でも、Pull Request上でテストが失敗するため開発チームで自動テストがメンテナンスされることになります。
開発チームでは上記のような議論を行ない、結論としてメリットのほうが大きいと判断して、E2E自動テストをプロダクトリポジトリに取り込むことにしました。
自動テストの取り込みの手順
自動テストをプロダクトリポジトリに組み込むと決めたあと、移行戦略を練りました。 一度に全てを移行することも不可能ではないものの、一度に移行すると問題の切り分けが難しく現実的ではないからです。
戦略と言っても少しずつ移行していっただけなので難しいことは何もしていません。 スプリントの進行に影響がないように、以下のようにタスクを最小単位に分割して進めました。
- まずは自動テストが動く土台を移植する
- 土台の上でテストが1つ動くようにする
- 全テストを移植する
幸いにもQAグループ内に知見を持ったメンバーがいたため、協力を仰ぎながら無事に移行できました。
プロダクトリポジトリに取り込んでどう変わったか
機能実装やバグ修正に応じて自動テストが失敗するようになるため、自動テストが確実にメンテナンスされるようになりました。 これによりE2E自動テストが開発チームでメンテナンスされるようになり、チームで品質保証を行なう体制構築の一助になりました。
また、懸念していたビルド時間が長くなる問題は、E2E自動テストのjobを他のCIのjobと並列に実行することで解決しており、1分程度の増加におさえられています。
成功した要因
今回の自動テスト取り込みが成功した要因ですが、E2E自動テストによる成功体験を開発チームで持っていたことが挙げられると思います。
「最初からプロダクトリポジトリで実装していればこんなことにはならなかったのでは？」と思う方が多いのではないでしょうか。 ですが、E2E自動テストは保守コストの高さや安定性の問題で、必ずしもビルドパイプラインに組み込みたい！と思っている人だけではありません。
独自リポジトリでE2E自動テストを作成・実行することでバグを発見し、自動テストが有用だという実例を事前に提供できていたからこそ、開発チームメンバーから組み込みたい！という提言をもらうことに繋がったのだと思っています。
最終的に多くの人が協力してくれたのも、この実績があったからこそだと思います。
おわりに
今回はE2E自動テストを独立したものからプロダクトに取り込むという内容をお届けしました。 似たような境遇の方などの参考になれば幸いです。
SmartHRのQAグループではこのような技術的なチャレンジも積極的に行なえます。 品質課題を技術で解決していきたい！などSmartHRのQAに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。 みなさまのご応募お待ちしております！
We are Hiring !
最後まで記事を読んでいただき、ありがとうございました。 SmartHRのQAに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。 カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気軽に聞きにきていただけたら嬉しいです。 みなさまのご応募お待ちしております！
