この記事はモチベーションクラウドシリーズ Advent Calendar 2022 13日目の投稿です。
弊社ではテックブログもやっておりますので、宜しければこちらもどうぞ！
https://link-and-motivation.hatenablog.com/
はじめに
リンクアンドモチベーションでQAエンジニアをしています。
私はこれまでプロダクト開発に従事していたのですが、紆余曲折あり10月からQAエンジニアとして
関わることになりました。
そんな私が最初に着手したのがAutifyの運用改善なので、それについて書いていきます！
Autifyの導入後から半年の状況
弊社はAutifyを約1年前に導入しました。
Autifyとは...
ブラウザ操作を記録するだけでテストが ノーコード で 誰にでも簡単 に作れるツール
導入当初は、手動で行なっていたリグレッションテストの工数が削減されるということで、開発者からも歓喜の声が広がっていました。しかし、それから数ヶ月後にあるプロダクトの開発チームにおけるAutifyの状況はこんな感じでした。
私：「リリースする際に、Autifyが成功していることを確認してますか？」
開発者：「。。。いつもは、、、していません。たまに見ます。」
気づいたら、Autifyが何日も落ちた状態が続いているなんてこともありました。
下記の結果は、当時のAutifyの直近1ヶ月の週ごとの実行結果になります。
この落ちていた原因は、メンテナンス対応の漏れであったり、flakyなテストになっていたことが原因でした。
いずれにしろ、Autifyが健全に利用されておらず、効果を発揮していない状況でした。
課題
早急にこの状態を打破する必要があると考えました。
自分の仮説では、下記の図ようなステップで、
・Autifyって信頼できないもの
・Autifyは、実行するのに面倒なもの
そして、その結果
・Autifyを見なくなる
状態となり、Autifyが運用されていない状態を作り上げたのではと思っています。
実際、僕自身が開発者としてAutifyを利用していたこともありましたが、実際に見られた場面もいくつかありました。
最終的に、Autifyが正しく実行されて、機能する状態を作るためには、
下記の課題を解消する必要があると思いました。
・Autifyの成功率が低い
・Autifyの実行時間が長い
・Autifyが見られない・無関心なものになってる
※Autifyがいけていないのではなく、私達の書いたシナリオがいけていないという意味です。
解決策
Autifyの成功率の向上
そもそも、Autifyを使って実行するようなE2Eテストは、
他のユニットテストやintegrationテストに比べて、偽陽性になるテストが多いです。
偽陽性と偽陰性～自動テストの信頼性をむしばむ現象を理解する～
その理由は大きく2つです。
・脆いテスト
ちょっとしたUIの変更でもテストが落ちてしまいます。
・Flakyなテスト（実行結果が不安定なテスト）
環境変数などが漏れていたり、画面遷移の時間が異なってしまうとコードを変更していないのに
、テストが落ちることがあります。
一方で、Autifyは偽陽性になることを防ぎ、メンテナンスなどを削減するために、
AIがリリースのたびに変更されるUIの変化を監視します。そして、テストシナリオを自動的に
アップデートしてくれます。
ただ、これらの精度もまだ高いわけではなく、上記の問題で落ちてしまうことがあります。
これらを解決するために、意図的に待機ステップを入れたり、ロケータ機能を使って、要素の指定を行うことで、AIの誤検知を防いだりできます。
ステップの設定方法
ロケータの設定方法
Autifyの実行時間の削減
改善前のAutifyの実行時間は下記でした。
1つのAutifyを実行するのに、1h以上かかっていました。
実行時間を削減するために大きく下記の2つをしました。
・不要なシナリオテストの削除
シナリオテストの中には、同じような繰り返し操作のテストを実行している箇所があり、それが実行時間の一番のボトルネックになっていました。Autifyで担保すべきは、下記だと判断し、不要なシナリオを削除しました。
・FEとBEの疎通確認
・最低限の重要な顧客シナリオ
※Autifyで実行するE2Eテストはよく見かけるテストピラミッドの最上層に位置するものなため、カバレッジを広げすぎることはアンチパターンと言われています。これをしてしまうと、メンテナンスのコストが増えたり、実行時間が増えてしまうなど、運用する上で大変です。
テストのピラミッドを3分で理解する
・シナリオテストの並列化
複数のシナリオテストを実行していく中で、直列で実行されていたものを並列実行に変えました。
一番ボトルネックになっていたシナリオテストが40 minほどだったので、それを並列にすることで、
半分以上の時間削減につながりました。
Autifyの運用体制の構築
開発チームの中で、Autifyが見られない・無関心な状態になってしまったので、そこから脱却するためにAutifyを運用する体制を作りました。
1つのプロダクトに関わるチームが4つ存在していたため、各チームから一人ずつAutify運用の担当者を選定し、各チームがリリースするまでにAutifyが成功する状態を見るという体制を作ってもらいました。
各Autify運用の担当者には、そもそもAutifyを利用する意義から共有し、定例の場を設け、定期的にAutifyが運用できているかを確認する状態を作りました。
改善後の状況
成功率は、70-90%（改善前に比べて +約50%）
実行時間は、最大22 min（改善前に比べて -約50%）
となり、どちらも改善傾向にあります。
下図が月ごとの推移ですが、徐々に改善されているのがわかります。
また、開発チームでAutifyの結果を確認してからリリースするという体制も作られ、より品質に安心を持った状態でのリリースができるようになりました。
今後のAutifyの運用
理想としては、開発チームの全員が品質を大事にするという文化を形成し、
Autifyの運用・改善も開発チームが自律的に行なっている状態を目指したいと思っています。
そのためにも、Autifyの成功率や実行時間がどうなっているかを開発者にもわかる状態を作り、
一定の基準値を超えれば改善を行うルールや仕組みを整えていきたいと思います。
少しでも、この記事が参考になれば幸いです。
Autifyのダッシュボード作成にあたって、こちらの記事を参考させていただきました。
Autify用のダッシュボードの作り方