プロダクトエンジニアリング部の千葉です。 LIFULL HOME'S不動産査定とホームズマンション売却の開発に携わっています。
この記事では、売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介していきます。
売却査定サービスにおけるE2Eテストについて
環境
売却査定サービスではE2Eテストを自動化するためのフレームワークであるTestCafeを使用したテストがデプロイ時と毎朝定時に実行され、実行結果がSlackに通知されます。
詳細については、こちらの記事をご覧ください。 www.lifull.blog
テスト観点
以下の4項目についてテストを行っています。
- Botでページを開いた際のHTTPステータスコード200の検証
- モバイル端末でページを開いた際のHTTPステータスコード200の検証
- PC端末での主要導線の確認
- モバイル端末での主要導線の確認
高速化の取り組み
背景
E2Eテストの課題として、デプロイからテスト終了までの待ち時間の長さが挙げられました。
通常、テストの実行には30分以上かかり、場合によっては60分を要することもありました。
取り組み1 - 項目の精査と方法の最適化
主要導線の確認では通常、物件種別と所在地の入力から入力画面、会社選択画面、確認画面を経て、完了画面までの一連の流れをテストし、完了画面に遷移できることでテストの成功としていました。
この一連のフローで、各ステップにおいて次の項目を確認していることになります。
- 物件種別と所在地の入力を行うことで入力画面に遷移できること
- 入力画面で入力を行うことで会社選択画面に遷移できること
- 会社選択画面で会社選択を行うことで確認画面に遷移できること
- 確認画面から完了画面に遷移できること
物件種別や所在地に応じて入力画面の入力項目が変わるため、それに応じたテストをそれぞれ実施していました。
しかし、会社選択画面以降のプロセスは同じにもかかわらず、それぞれ完了画面までのテストを行っていたため、同様のテストを繰り返すことになっていました。
また、プロダクトコードの不備や画面読み込みの遅延で、必須項目が入力できず会社選択画面に進めない場合、以降のテストが実行できないという問題がありました。
さらに、TestCafeではユーザーの操作を模倣し、カーソルの移動、クリック、文字入力といった動作を通じてテストを行います。
そのため、1つのフォームの入力にも時間がかかります。
この問題を解決するために、以下のようにテストの役割を分割しました。
- 入力画面のテスト
- 入力画面で入力を行うことで会社選択画面に遷移できることを確認
- 会社選択画面のテスト
- 会社選択画面で会社選択を行うことで確認画面に遷移できることを確認
また、 会社選択画面のテストでは、入力画面での入力はDOM操作で行い、核心的なテストプロセスである会社選択画面ではUIテストを行うことで実行時間を削減しました。
各観点を独立したUIテストで実行することにより、物件種別と所在地の入力から完了画面に至る一連のフローテストはDOM操作を活用することにしました。
これにより、不必要なテストを排除するとともに、ユーザー操作のステップを省略し直接変更を行うことで、テスト実行時間の大幅な削減を実現しました。
取り組み2 - 処理の共通化
物件種別と所在地の入力では、たとえば「査定可能な会社が1社しか存在しないエリアにおいて、会社を選択しなくても確認画面に進める」というテストを実施したい場合、査定可能な会社が1社のみの所在地を入力する必要があります。
LIFULL HOME'Sをご利用の会員様（不動産会社様）の状況に応じて、各エリアの会社数は常に変動します。
このテストを実行するため、所在地の入力時には東京都⚪︎⚪︎区を入力し、会社数が2社以上の場合は次のエリア（東京都△△区）を入力し、さらに2社以上であればほかのエリア（東京都♢♢区）へと、期待した結果が得られるまで繰り返していました。
その結果、核心的なテストプロセス開始前の段階で削減可能な不要なコストがかかっていました。
さらに、この方法を複数のテストケースで同様に行っていたため、時間とリソースが無駄に消費されていました。
そこで、テスト開始前に会社が1社のエリアを特定し、そのうえでテストを行う処理を追加することでこの問題を解決しました。
取り組み3 - ジョブの最適化
4項目のテスト観点に対して、それぞれ1ジョブずつ合計4ジョブで実行していました。
ページを開いた際のHTTPステータスコード200の検証については、各3ジョブに分割し、主要な導線の確認は、UIテストとDOM操作によるテストの各2ジョブに分割しました。
これにより、全体で10ジョブとすることで1ジョブあたりの実行時間が削減され、全体の実行時間を削減しました。
一方で、ジョブが増えることでSlack通知が増えるという懸念もありました。
ジョブ1つにつき1つのメッセージがSlackチャンネルに投稿されていたため、自動テスト実行1回につき4つのメッセージが投稿されていましたが、これが10個になると情報を見逃してしまうリスクもありました。
そこで通知を改善しました。方法は以下の通りです。
- CodeBuildのDOWNLOAD_SOURCEビルドフェーズ（テスト開始前にソースコードを取得するフェーズ）開始時に親メッセージを投稿する
- 各ジョブ終了時にそのメッセージのスレッドに返信を行う
- 失敗の場合はSlackの機能を用いて返信をチャンネルにも投稿する
- すべてのジョブが終了したら親メッセージを完了を示した文言で上書きする
これにより、Slackチャンネルに流れるメッセージの数は減りつつも、自動テストの終了と失敗を見逃さないようなしくみにしました。
取り組み4 - 実行の並列化
1ジョブあたりの実行時間をさらに削減するために実行の並列化を行いました。
TestCafeの並列機能を使用して、複数のインスタンスを起動し、これらのインスタンス間でテストの作業負荷を分担することで実行時間を削減しました。
取り組み5 - タイムアウト設定
予期しない理由でビルドが途中停止してしまった際に60分経過するまで失敗通知が送信されないという問題がありました。
これはCodeBuildのタイムアウト設定を行っていなかったためです。
CodeBuildには設定した時間内にビルドが完了していない場合にビルドを停止する機能がありますが、何も設定していない場合はデフォルトで60分に設定されます。
タイムアウトを20分に設定することで、失敗が発生した場合でも迅速に結果を把握できるようにしました。
これにより、CodeBuildの実行にかかった時間に基づいた課金が軽減され、コストカットにもつながりました。
結果
取り組みの結果は以下の通りです。
実行時間には多少のばらつきがありますが、おおむね一定の時間で完了します。
実行時間を大幅に削減でき、高速化を実現しました。
また、E2EテストにかかるCodeBuildの月々のコストも約100ドルから約50ドルへと削減できました。
全体
改善前：31分0秒
改善後：11分45秒
Botでページを開いた際のHTTPステータスコード200の検証
改善前：13分23秒
改善後：7分59秒
モバイル端末でページを開いた際のHTTPステータスコード200の検証
改善前：13分53秒
改善後：8分2秒
PC端末での主要導線の確認
改善前：29分56秒
改善後：5分53秒
モバイル端末での主要導線の確認
改善前：20分6秒
改善後：5分39秒
まとめ
売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介しました。
最後に、LIFULLではともに成長できるような仲間を募っています。
よろしければこちらのページもご覧ください。
