はじめに

「HRMOS タレントマネジメント」（以下、「HRMOS」）では1年間かけて、自動 E2E テストの導入から開発・運用をしてきました。
最終的には、画像のように ChatOps でいつでも簡単に開発者が E2E テストを実行できる環境が整備されました。

この記事では、1年間で溜まった知見をもとに主に以下の内容に触れていきます。

自動 E2E テストの導入や、その活用法に悩んでいる方の助けになれば幸いです。

Slack でコマンドを実行すると E2E テストが実行される仕組みを運用
テスト結果が Slack 通知される

「HRMOS」における自動 E2E テストの必要性

「HRMOS」では日々ユニットテスト、インテグレーションテストなどの様々なテストが CI で動いています。 加えて、開発者も branch を開発環境にリリースして、手動テストを実施することで変更の検証を行なっています。

しかしながら、feature branch を merge することでリリースされる手法を採用しているため、リリースサイクルが非常に早く、プロダクトの規模が拡大するにつれて開発者が手動テストを実施する効率が低下してきました。

そこで、開発者の工数を抑えつつ広い範囲のテストを実施できる「自動 E2E テスト」の導入を決定しました。

「HRMOS」の branch フロー。feature branch を merge すると即座にリリースされる

自動 E2E テストツールの選定

まずはツールの選定です。
世の中にあるツールのうち、（現時点で）「HRMOS」としてベストであろうモノを選択しました。

前提条件

そもそも自動 E2E テストは形骸化しがちです。 実行時間が長かったり、メンテナンスが頻繁に必要になったり、開発者以外が触れなかったりすることが経験的に主要な要因です。

そこで、ツールは以下の前提条件を満たしたものを選びました。

候補の中から Autify を選択

検討段階では候補はいくつもありました。 あくまで一例ですが、これらのツールです。

その中で Autify を選んだ理由は以下です。

画面操作の自動記録と問い合わせに対するスムーズな対応は、開発者以外が実装・メンテナンスする上で外せない要素であったので、非常に魅力的でした。 一方で、利用料金やテストの部分実行などに課題はありましたが、それを補って余りあるメリットだったので採用に踏み切りました。

このあたりの詳細はまた別の記事で書きたいです。

Autify のプロトタイピングと導入

Autify が第一候補として選択されたので、プロトタイピングして実用性を検証しました。

その結果、Autify の特徴である

のおかげで、実働期間は1週間程度で以下を達成できました。

「CSS を変更したら壊れた」「要素の順番が変わると壊れた」などの、E2E テストでありがちな不安定さも特にありませんでした。ありがとう Autify の AI くん。

テストとしての実用性・安定性は十分で、運用性も高いということが分かったため、「HRMOS」への導入を決定しました。

テストケースの実装

主に2つのステップで構成されます。

テストケースの列挙

すでに手動テストを実施しているので、そのテストケースがまとまっています。 しかし不要なケースも多かったり、そのまま自動化すると無駄が多い部分もありました。
このタイミングでスリム化も同時に進行させることで、メンテナンスしやすいテストケースを再定義しました。

テストケースの実装

必要なテストケースが揃ったので、あとは実装するだけ…..とはいかないです。 何度実行しても、たとえ途中で失敗しても冪等になるように制御したり、一般的に遅くなりがちなE2Eテストなので、並列実行に耐えられる設計にしたりと考慮すべき事項は多々あります。

初期の実装は Autify に詳しい開発者が爆速で進めてくれました。 このあたりも後々記事にできたら嬉しいです。

DevOps 連携によるさらなる活用

テストケースの実装と並行して、いくつかの課題の解決を図りました。

従来の課題

冪等性の担保

E2E テストも当然冪等であるべきです。 ただし、それを実現するのは容易ではありません。
例えば「ユーザを新規登録する」テストを単純に実装するのであれば、以下のようにクリーンアップ処理が必要になります。

  1. ユーザを新規登録する
  2. 登録したユーザを削除する

しかし、ユーザの削除処理に失敗した場合は、登録したユーザが残ります。 次回以降のテストはゴミデータ（不確定データや欠損データなど）が残った状態で実行され、多くの場合で失敗します。

開発環境とテスト実行環境の分離

「HRMOS」の開発環境では、様々な開発者が動作確認やデータ操作を行なっています。
branch ごとにアプリがリリースされる環境や、業務的な整合性のないデータを含む環境で E2E テストを安定して実行するのは現実的ではありません。 E2E テスト専用のクリーンな環境を提供すべきです。

インフラレイヤでの解決

Autify が実行されるまでのフロー

上記の課題を解決するため、インフラ領域にも精通している SRE チームを巻き込んで、インフラに手を入れました。

AWS 上に、開発環境のものとは別の ECS Cluster を作成し、ドメインを分けました。 また、本番環境と同様にゴミデータを含まず、整合性の取れた正しいデータのみを含む DB （クリーン DB）を用意しました。 その後、以下のフローを実行できるようにしました。

  1. Slack Bot 経由で実行指示
  2. AWS Lambda が GitHub Actions を起動
  3. GitHub Actions が CodeBuild を起動し、以下を実行
    1. クリーン DB を E2E 実行環境に複製
    2. 指定したバージョンのアプリを E2E 実行環境にリリース
  4. GitHub Actions が Autify API 経由でテストを実行

これにより、クリーン DB を毎回参照できる実行環境と、自動化されたワークフローを得られました。 SRE チームの皆さん、本当にありがとうございました。

GitHub Actions による自動実行フロー

運用を通して得た結果と知見

E2E テストの運用を開始して1年が過ぎました。 その間、開発者は主に以下のシチュエーションで E2E テストを活用しています。

その中で得られた結果と知見を共有します。

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 テストの中には、変更が頻繁に必要なものであったり、変更に時間がかかるものがあります。そういった項目には別のテスト手法を用いることで、効率的な自動テスト運用を実現しています。

「HRMOS」での E2E テストの運用ポリシー

また、実装するテストケースをハッピーパスに集中させることで、アプリの細かい変更に対しても頻繁に壊れることがない仕組みとなっています。

Try: ドキュメントの必要性

Autify はユニットテストなどと異なり、コードベースでの管理が難しいです。 そのため実装されているテストケースはドキュメントとして別途管理する必要があります。

「HRMOS」では以下のように、どんなテストケースがあるのかをドキュメントにまとめています。 テストとドキュメントの二重管理にはなりますが、この方針によりテストケースの一覧性を担保しています。

テストケースのドキュメント

おわりに

「HRMOS」での自動 E2E テストの導入から開発、運用方法のご紹介をしました。

「プロダクトの成長スピードを止めずに、いかに自動化によって開発効率・品質レベルを上げていくか」という難しい問題に悩んでいる開発者の方は多いと思います。 この記事が参考になれば幸いです。

また最後に、Autify の初期実装を爆速で進めてくださった東海林さん、インフラ領域を整備していただいた SRE チームのみなさんには、本当に感謝しております。 ありがとうございました！

青木 大樹
青木 大樹

HRMOS EXのソフトウェアエンジニア。2021年入社。胃が弱い