はじめに
「HRMOSタレントマネジメント」(以下、「HRMOS」)では1年間かけて、自動E2Eテストの導入から開発・運用をしてきました。
最終的には、画像のようにChatOpsでいつでも簡単に開発者がE2Eテストを実行できる環境が整備されました。
この記事では、1年間で溜まった知見をもとに主に以下の内容に触れていきます。
- 「HRMOS」における自動E2Eテストの導入の理由
- 自動E2Eテスト(Autify)の導入までの道筋
- 自動E2EテストのDevOps連携
- 自動E2Eテストの活用による品質担保
自動E2Eテストの導入や、その活用法に悩んでいる方の助けになれば幸いです。
「HRMOS」における自動E2Eテストの必要性
「HRMOS」では日々ユニットテスト、インテグレーションテストなどの様々なテストがCIで動いています。 加えて、開発者もbranchを開発環境にリリースして、手動テストを実施することで変更の検証を行なっています。
しかしながら、feature branchをmergeすることでリリースされる手法を採用しているため、リリースサイクルが非常に早く、プロダクトの規模が拡大するにつれて開発者が手動テストを実施する効率が低下してきました。
そこで、開発者の工数を抑えつつ広い範囲のテストを実施できる「自動E2Eテスト」の導入を決定しました。
自動E2Eテストツールの選定
まずはツールの選定です。
世の中にあるツールのうち、(現時点で)「HRMOS」としてベストであろうモノを選択しました。
前提条件
そもそも自動E2Eテストは形骸化しがちです。 実行時間が長かったり、メンテナンスが頻繁に必要になったり、開発者以外が触れなかったりすることが経験的に主要な要因です。
そこで、ツールは以下の前提条件を満たしたものを選びました。
- (費用面で)ローコストで運用できる
- 開発者以外が実装・メンテナンスできる
- コードメンテナンスが最小限である:開発者以外がメンテナンスすることがあるため
- ソフトウェアメンテナンスが必要ない:nodeやWebDriverのバージョンなどに左右されない
- サーバメンテナンスが必要ない:JenkinsやDockerなどに左右されない
候補の中からAutifyを選択
検討段階では候補はいくつもありました。 あくまで一例ですが、これらのツールです。
その中でAutifyを選んだ理由は以下です。
- ユーザーの画面操作を自動的に記録することで、圧倒的に高速で実装ができた
- Autifyサポートの方が問い合わせに対し迅速に相談に乗ってくれた
画面操作の自動記録と問い合わせに対するスムーズな対応は、開発者以外が実装・メンテナンスする上で外せない要素であったので、非常に魅力的でした。 一方で、利用料金やテストの部分実行などに課題はありましたが、それを補って余りあるメリットだったので採用に踏み切りました。
このあたりの詳細はまた別の記事で書きたいです。
Autifyのプロトタイピングと導入
Autifyが第一候補として選択されたので、プロトタイピングして実用性を検証しました。
その結果、Autifyの特徴である
- GUI操作でテスト実装が完結する
- AIによる要素の自動判定
- 公開APIの存在
のおかげで、実働期間は1週間程度で以下を達成できました。
- 主要機能群のミニマムなテストの実装
- CI経由でのテスト実行
「CSSを変更したら壊れた」「要素の順番が変わると壊れた」などの、E2Eテストでありがちな不安定さも特にありませんでした。ありがとうAutifyのAIくん。
テストとしての実用性・安定性は十分で、運用性も高いということが分かったため、「HRMOS」への導入を決定しました。
テストケースの実装
主に2つのステップで構成されます。
テストケースの列挙
すでに手動テストを実施しているので、そのテストケースがまとまっています。
しかし不要なケースも多かったり、そのまま自動化すると無駄が多い部分もありました。
このタイミングでスリム化も同時に進行させることで、メンテナンスしやすいテストケースを再定義しました。
テストケースの実装
必要なテストケースが揃ったので、あとは実装するだけ…..とはいかないです。 何度実行しても、たとえ途中で失敗しても冪等になるように制御したり、一般的に遅くなりがちなE2Eテストなので、並列実行に耐えられる設計にしたりと考慮すべき事項は多々あります。
初期の実装はAutifyに詳しい開発者が爆速で進めてくれました。 このあたりも後々記事にできたら嬉しいです。
DevOps連携によるさらなる活用
テストケースの実装と並行して、いくつかの課題の解決を図りました。
従来の課題
冪等性の担保
E2Eテストも当然冪等であるべきです。
ただし、それを実現するのは容易ではありません。
例えば「ユーザを新規登録する」テストを単純に実装するのであれば、以下のようにクリーンアップ処理が必要になります。
- ユーザを新規登録する
- 登録したユーザを削除する
しかし、ユーザの削除処理に失敗した場合は、登録したユーザが残ります。 次回以降のテストはゴミデータ(不確定データや欠損データなど)が残った状態で実行され、多くの場合で失敗します。
開発環境とテスト実行環境の分離
「HRMOS」の開発環境では、様々な開発者が動作確認やデータ操作を行なっています。
branchごとにアプリがリリースされる環境や、業務的な整合性のないデータを含む環境でE2Eテストを安定して実行するのは現実的ではありません。
E2Eテスト専用のクリーンな環境を提供すべきです。
インフラレイヤでの解決
上記の課題を解決するため、インフラ領域にも精通しているSREチームを巻き込んで、インフラに手を入れました。
AWS上に、開発環境のものとは別のECS Clusterを作成し、ドメインを分けました。 また、本番環境と同様にゴミデータを含まず、整合性の取れた正しいデータのみを含むDB (クリーンDB)を用意しました。 その後、以下のフローを実行できるようにしました。
- Slack Bot経由で実行指示
- AWS LambdaがGitHub Actionsを起動
- GitHub ActionsがCodeBuildを起動し、以下を実行
- クリーンDBをE2E実行環境に複製
- 指定したバージョンのアプリをE2E実行環境にリリース
- GitHub ActionsがAutify API経由でテストを実行
これにより、クリーンDBを毎回参照できる実行環境と、自動化されたワークフローを得られました。 SREチームの皆さん、本当にありがとうございました。
運用を通して得た結果と知見
E2Eテストの運用を開始して1年が過ぎました。 その間、開発者は主に以下のシチュエーションでE2Eテストを活用しています。
- main branchでの日次実行
- 影響範囲の広いPRの動作確認
- ライブラリやフレームワークのバージョンアップ時の動作確認
その中で得られた結果と知見を共有します。
Good: 開発速度とバグ発見頻度の向上
必要な時にSlackでコマンドを実行することで、E2Eテスト専用環境でAutifyが走ります。 特に「HRMOS」は頻繁にリリースするので、その度に開発者の工数を奪わずに広範囲のテストが実施できるのは非常に効果的でした。自動E2EテストはDBをコピーしたり、アプリをデプロイしたするので時間はかかりますが、開発者はその間に別の作業に取り掛かれるので、テストにかける人間の工数は減りました。
そして最近では、自動E2Eテストは特定条件でUI操作ができないバグや、フレームワークアップグレード時に画面遷移のバグを発見してくれてます。
さらに、いままで「HRMOS」はGoogle Chromeを対象ブラウザとしていましたが、今回Microsoft Edgeも対象として広げることを計画していました。 そこでMicrosoft Edgeに対してAutifyを流すことで「現状、どの程度対応できてるの?」という検証を実施しました。 その結果、自動E2Eテストのテストケースはすべてパスし、「HRMOSタレントマネジメントはMicrosoft Edgeにもすでに対応できている」と判断し、晴れて対象ブラウザにMicrosoft Edgeを加えることができました。
このように自動E2Eテストのおかげで、品質が要件を満たしている・いないことを低コストで確認できています。
Good: 開発者による自律的なメンテナンス
Autifyはメンテナンスが容易で、テストの追加も開発者が素早く実施できます。そのため、「HRMOS」では開発者が日々、自動E2Eテストのメンテナンスをしています。
これによって「基本的に自動E2Eテストは開発チームの持ち物である」という意識が浸透しました。
ユニットテストやインテグレーションテストと同様に、自動E2Eテストも開発者が自律的に開発・運用することで、さらにシフトレフトが進んでいます。
Try: 実行すべきテストの取捨選択の必要性
Autifyはページの要素が少し変わったとしても安定してテストを実施してくれるので、頻繁にテストが壊れるということはないです。 しかし、無造作にテストケースを作ってしまうと壊れる確率は高まるので避けるべきです。
そこで「HRMOS」では主に以下のポリシーでテストを作成して、ポリシーに沿わないものは極力E2Eテスト以外のテスト手法で担保しています。 E2Eテストの中には、変更が頻繁に必要なものであったり、変更に時間がかかるものがあります。そういった項目には別のテスト手法を用いることで、効率的な自動テスト運用を実現しています。
また、実装するテストケースをハッピーパスに集中させることで、アプリの細かい変更に対しても頻繁に壊れることがない仕組みとなっています。
Try: ドキュメントの必要性
Autifyはユニットテストなどと異なり、コードベースでの管理が難しいです。 そのため実装されているテストケースはドキュメントとして別途管理する必要があります。
「HRMOS」では以下のように、どんなテストケースがあるのかをドキュメントにまとめています。 テストとドキュメントの二重管理にはなりますが、この方針によりテストケースの一覧性を担保しています。
おわりに
「HRMOS」での自動E2Eテストの導入から開発、運用方法のご紹介をしました。
「プロダクトの成長スピードを止めずに、いかに自動化によって開発効率・品質レベルを上げていくか」という難しい問題に悩んでいる開発者の方は多いと思います。 この記事が参考になれば幸いです。
また最後に、Autifyの初期実装を爆速で進めてくださった東海林さん、インフラ領域を整備していただいたSREチームのみなさんには、本当に感謝しております。 ありがとうございました!