こんにちは。AutifyのTest Executionチームでバックエンドエンジニアをしている藤です。このチームでは普段、Autify for Webのテスト実行エンジンにまつわる機能開発を行なっています。

Autifyでは以前から、テストを高速にしてほしいとの要望をお客様よりいただいていていました。そこでTest Executionチームでは2023年8月から10月にかけてテスト実行時間の短縮に取り組んできました。この記事ではその取り組みの結果を紹介します。

Autifyのテスト実行が約20%高速になりました

はじめに私たちが取り組んできたテスト高速化の結果をお見せします。

以下のグラフはAutify for Webのテスト実行時間（秒）の中央値を月別で表示したものです。テスト実行時間は一つのシナリオのテストが開始されてから完了するまでの時間を計測しています。開始されるまでの待機時間は含みません。7月と8月は改善前、9月は改善途中、10月と11月は改善後のデータです。改善前は125秒程度だったのが、改善後は100秒近くになっているのが読み取れます。このように中央値で見るとテスト実行時間がおよそ20%短縮されたことがわかります。

E2Eテストはなぜ高速なほうが良いのか

ところで基本的な話題に立ち返ると、なぜE2Eテストの実行は高速なほうが良いのでしょうか。これはノーコードのE2Eテストに限った話ではありません。

手短に重要な点を一つだけ挙げます。開発チームが自動化されたE2Eテストを毎回のリリース前に実行している前提のもとで、高速なE2Eテストはリリースの頻度を上げることを可能にし、ソフトウェアの品質と開発チームの生産性を改善します。

E2Eテストはその性質上、テストピラミッドの下段に位置するユニットテスト等と比べると実行速度が格段に遅いです。それはE2Eテストが他のテストよりも複雑だからです。テスト内の一つ一つの操作がUIからデータベースまで複数の層をまたいで行われる上、多くの操作を順に実行する必要があるため、一つのテストシナリオの実行に数分かかることも珍しくありません。

そのためE2Eテストはリリースパイプライン上のボトルネックになりやすい箇所です。単純な例として、3時間で完了するE2Eテストと10分で完了するE2Eテストがあるとします。前者ではリリース頻度は最大でも1日に1回が限度かもしれませんが、後者なら1日に複数回リリースできる可能性があります。

このように、E2Eテストが高速であればリリース頻度を週1回から1日1回、さらには1日複数回へと上げていくことが可能になります。それにより開発者は迅速なフィードバックを受け取ることができ、不具合や問題を早期に特定・修正することができるようになります。

テストが遅くなるAutify固有の要因

E2Eテストは一般的に実行時間が長くなりやすい宿命にありますが、それに加えてノーコードツールであるAutifyに固有の要因もあります。

Autifyではマウス操作等でレコーディングしたシナリオを、特別なコードを書くことなく実行できますが、このような直感的な操作性を実現するためにいくつもの工夫が背後で行われています。

たとえば要素探索時の待機です。ユーザーがレコーディングした要素は、テスト実行の際にはステップの開始時点で存在するとは限らず、非同期通信をはさんで数秒後に現れることもあります。特にSPA(Single Page Application)ではそのような実装が多く見られます。このように非同期に現れる要素に対してもテスト実行エンジンが正しく要素を見つけられるようにするため、期待する要素がページ上に存在しない可能性のある状況では、Autifyのテスト実行エンジンは要素が現れるまで一定の秒数だけ待機します。

ユーザーが明示的に待機を指示しなくてもいいように、テスト実行エンジンの側で要素探索時に「よしなに」待機する機能ですが、これが曲者で、テストを遅くする要因になります。

なぜでしょうか。掘り下げて考えてみます。

E2Eテストがコードで管理されている場合には、要素探索時の自動待機は話がぐんと単純になります。ユーザーは要素をXPathなどのロケーターで指定するため、テスト実行時には指定されたロケーターに厳密に合致する要素が現れるまで待てばよいでしょう。どんな要素を待つべきかはテストコードの中に明確に表現されており、そこに曖昧さはありません。

ところがノーコードのE2Eテストでは一筋縄ではいきません。ノーコードでは要素探索が「推測」だからです。ユーザーの意図する要素（期待要素）が現れるまで待つべきかどうかの判断以前に、どの要素が期待要素であるのかをテスト実行エンジンの側で判断する必要があります。コードで書かれたE2Eテストと違って、どの要素が期待要素であるかは明確に表現されておらず、ユーザーがレコーディング時に操作した要素の情報をもとに推測することになります。

言いかえるとノーコードのE2Eテストにおける要素探索には、精度というものがあります。期待要素を一発必中で当てることはできず、期待要素とは別の要素を探し当てる、あるいは期待要素がページ内に存在しないときに別の似た要素を探し当てるリスクが常に存在します。これはどのような要素探索戦略を採用するとしても、要素探索が非決定論的に行われる限りはつきまとう問題です。

要素探索を推測で行う以上、要素探索時の自動待機にも精度があります。待機すべきときに待機しない、あるいは待機すべきでないときに待機するという誤検出の問題が存在します。特に、待機の必要ないときに待機するケースが多ければ、自動待機はテストを遅くする要因になります。

Autifyのテストを高速化したい

初めに紹介したとおり、Test Executionチームではテスト実行時間の短縮に取り組むことになりました。

パフォーマンス改善の定石は何よりもまずボトルネックの特定です。何がテストを遅くしている最大の要因なのか。何を改善したら効率的かつ効果的にテスト実行時間を短縮できるのか。それを特定するためにデータの計測から始めました。

データを集めた結果、初めからあたりをつけていたのですが、案の定というか想定していた以上に、要素探索時の自動待機がテスト実行時間に大きく影響を与えていることがわかりました。全テスト実行時間のうち自動待機が40%を占めており、そのうち70%が不要な待機だったのです。ここに最適化の大いなる余地がありそうです。

そこで私たちは要素探索時の不要な自動待機を減らすという施策を講じることにしました。

テストを高速化する。ただし既存のテストを壊さずに

そうと決まれば善は急げ、とはいきません。要素探索時の不要な自動待機を減らすという方針は決まったものの、重要な制約があります。それは既存のテストを壊さないことです。

Autify for Web上では毎日数万回のE2Eテストが実行されており、そのうちの多くが週1回以上定期的に実行されています。テスト高速化の結果、定期実行されているテストが突然失敗するようになったとしたらテストの信頼性を損なってしまいます。どのような最適化を行うにしても後方互換性の維持は外せません。

後方互換性を維持した最適化は、なかなか手強いものがあります。極端な話、仮にこの制約をとっぱらってよければ、自動待機機能そのものを撤廃することでテスト実行時間を40%削減できます。しかしそうすると定期実行されている既存のテストが失敗するようになります。自動待機機能には確かに不要な待機もあるものの、実際に非同期の要素が現れるのを待つケースもあるからです。ここで行いたい最適化は不要な待機だけを削減することです。

既存のテストを壊さずにテスト実行時間を短縮するため、私たちチームではいくつかの施策を行いましたが、その中で効果的だったものを一つ紹介します。

先に言及したとおり、Autify for Webで実行されているテストの多くは週1回以上定期実行されています。そこで私たちが目をつけたのはシナリオの実行履歴です。一つのステップに着目すると、過去の実行履歴から、待機が発生した際にその待機が本当に必要なものだったのかどうかを事後的に知ることができるはずです。

テスト実行時間を短縮する施策の一つで効果的だったものは、シナリオの過去の実行履歴を参照して、自動待機が必要かどうかを判定するというものです。アイデアとしては単純です。実際に実装に落とし込むには、過去のさまざまなテスト結果から、不要な待機が何回発生したらどの程度の確率で自動待機が不要と判定できるかといったデータ分析は必要でしたが、この施策は功を奏しました。

このアプローチは後方互換性を維持した改善という点で特に効果的でした。というのも、一部の自動待機がある日突然なくなるのではなく、個別のシナリオごとに過去のテスト実行履歴を参照して不要な自動待機を少しずつ減らしていくからです。

この施策の結果、最善ケースで10回以上実行されたことのあるシナリオに関しては、不要な自動待機が発生しないよう改善されました。

テスト高速化の結果

冒頭でも紹介したとおり、テスト実行時間を短縮する取り組みの結果、中央値で見るとテスト実行時間がおよそ20%短縮されました。平均値ではなく中央値を参照した理由は、テスト実行時間の分布はロングテールで、平均値が外れ値に影響されやすいからです。また、テスト全体ではなくステップの実行時間で見てもおよそ20%の短縮が観察されました。

一つ補足しておきたいのが、この結果はあくまでも全テスト実行時間に関するもので、個々のお客様のワークスペースごとに改善のばらつきは大きいということです。実行時間が10%程度しか短縮されなかったワークスペースもあれば、60%短縮されたワークスペースもありました。平均テスト実行時間がもともと長いワークスペースでは、改善の度合いが大きい傾向にあったようです。また、特にSalesforceのアプリケーションをテストしていただいているお客様のワークスペースでは、平均すると30%程度のテスト実行時間の短縮が見られました。

さいごに

いかがでしたか。このようにAutifyでは目に見えないところも含めて日々サービスの改善を行っています。これからもご愛顧のほどよろしくお願いいたします。
 
Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開しております。ぜひこちらからご覧ください。