🥑

リリース前のE2E自動テストを簡略化したけど、案外品質に影響はなかったし開発者体験はよくなったよという話

FukutomiQA

2025/02/14に公開

E2E テスト

idea

 ごあいさつこんにちは。マイベストでひとりQAをしているfukutomiです。
花粉症の季節がやってまいりました。つらいです。

いや、普段は薬で症状が出ないようにしているのでそれほどつらくはないのですが…。

いつか薬が効かなくなるんじゃないかという恐怖に怯えています。
さて、今回はリリース前のE2E自動テストを簡略化した話をします。

よろしくお願いします。

 なぜやったのかもともとマイベストではリリース前のE2E自動テストでけっこう詳細なリグレッションテストを実行していました。

全記事種に対してさまざまな動作確認を行うので時間はかかりますが、自動テストのおかげで防がれた障害もあったはずです。
しかし後述する様々な理由によりマイベストの開発スタイルと自動テストが相性が悪く、開発サイクルの速度を下げ、開発者体験を損なう状態になっていたので方針を変えることにしました。

 マイベストの開発サイクルマイベストは定期リリースを設定しておらず、基本的にはできたものからどんどんリリースしていく開発スタイルをとっています。

チケットひとつひとつにテスト環境が構築され、テストや受け入れチェックが終わったものからリリースされていくという感じで、規模感も文言変更から機能追加まで様々です。
その結果、現在マイベストでは1日平均14.1件のデプロイが行われています。

あんまり他社事例を知らないのですが、エンジニアが（業務委託も含めて）20人ちょっとの組織でこの件数はけっこう多いと言っていいのではないでしょうか。

Findy Team+より　2024年10月〜12月のデプロイ頻度

 肥大化して信頼性の低下したE2E自動テスト元々マイベストはいくつもの共通パーツを組み合わせてコンテンツが構成されていることもあり、ひとつの改修が与える影響範囲が大きくなりがちな傾向があります。

それをカバーするため、自動テストもかなり詳細に確認項目を用意していました。

詳細な自動テストの一例　ランキング表の絞り込み機能をテストしている
しかしその結果、どうしてもCIでの実行時間が延びてしまったり、環境要因による失敗が発生してしまっていました。

1実行にだいたい40分　ちょくちょく発生する失敗のようす
また、自動テストを厳密にやるとデータ更新にどうしても弱くなります。

例えばランキングの更新に伴いデータの件数が減るとそれだけでテストが落ちる、みたいなことが発生するわけです。

fukutomiからのかなしいアナウンス

ランキングの件数が10件以下になると「続きを見る」ボタンが表示されなくなり、自動テストが落ちる
このようなことが頻発するとどうしても自動テストに対する信頼性は低くなり、E2E自動テストがPassしていないのにそのままデプロイされちゃうことも発生してしまいます（というか発生しました）。
窓口になっているfukutomiへの問い合わせも増え、事情が事情だけに最優先で確認せざるを得ず、自分の生産性も下がります。いいことがあんまりない！ほんとに！

 開発サイクルとの相性の悪さめちゃくちゃ早い開発サイクルと、肥大化して時間がかかるようになった自動テスト。

まあなんとなくお察しいただけると思いますが、相性はよくないです。

開発チーム内でのテストが数分で終わるのに、E2E自動テストが終わらないのであと30分はリリースできませんみたいなことが頻繁に起きます。
もちろん自動テストがやっているのはいわゆるリグレッションテストなので、待つことに意味はあります。

人間が見つけられなかった不具合を見つけてくれる可能性もあるわけですから。

とはいえ、例えばただの静的文言変更でも数十分リリースを待たせるのはそれはそれで本意ではありません。

リリースまでのリードタイムを延ばしているだけで、開発者体験としてもあまりよくない状態です。

 E2E自動テストの実装方針を変えることにしました上述のとおりリリースの遅延につながっていることや、開発者体験を悪くしていることを鑑み、自動テストの実装方針を変更することとしました。

 実装方針を障害重要度判断基準に寄せることにしたマイベストには障害発生時の重要度判断基準があります。
自動テストの実装方針もこちらに寄せることとし、P0、P1の障害が検知できる程度にシンプルなテストを実装することとしました。具体的に確認する項目は下記のとおりです。
主要な各ページにアクセスできること（P0障害を防ぐ）
表示されている広告枠の数が正しいこと（P0障害を防ぐ）
各ページのメインコンテンツ領域が表示されていること（P1障害を防ぐ）

 テストコードはどうなったか当然、確認内容をシンプルにしたのでほとんどのテスト項目が消えました。

消えていったテストコードも全て自分が作ったものなのでちょっとだけ寂しいきもち。

ランキング表の操作、関連コンテンツエリアの表示確認、、、バイバイみんな。。。
逆にシンプルにしたことでできるようになったことも。

自動テストでアクセスするコンテンツをランダム化することができるようになりました。
テスト実行時にコンテンツのリストから無作為にひとつ抽出し、そのコンテンツに向かってテスト実行するような感じになっています。

いつも同じコンテンツを相手にするよりは信頼性が上がるかなと。

 その結果どんな感じですかねE2E自動テストの運用に破壊的な変更を加えたわけですが、実際様子はどうなのでしょうか。

 開発者体験やfukutomiへの問い合わせの件数ひとまず自動テストの実行時間は20〜25分ほどに収まるようになりました。

4割減くらいですかね。もっと早くしたい思いはあれど、一旦改善OKかなと。

また環境要因による失敗もほぼなくなりました。

なので最近は自動テストがPassしないままリリースされることはなくなりました（自分の見える範囲では）。

ひとまず実行時間は20〜25分ほどに収まるようになりました
またfukutomiへの問い合わせもほぼなくなり、自分の業務に邁進できるようになりました。

開発者体験はひとまず改善できたと言ってよさそうです。よかった。

 プロダクトの品質問題はこっち。

方針を変更したのが2024/12/19ごろなので、あれからまだ1ヶ月ちょっと。しっかりとした結果は出ていません。

なのでどれほどの効果があったのかを測るのはもうちょっと時間が経ってからとしたいですが、Findy Team+で変更障害率を見ると、少なくとも悪化はしていないように見えます。

Findy Team+より 2024/12/19に確認内容を変更してから、変更障害率は悪化していなさそう
実際、この期間で重大なP0、P1障害は発生していないので、自動テストは一定の役割を果たしていそうです。よかった。

 これからの展望E2E自動テストを簡略化しても品質には大きな影響を出さず、開発者体験の改善に成功しました。

自動テストで詳細な確認まで行うようにしたのも自分なのでちょっと複雑な感情ではありますが、大事なのはよいものをよい品質でできる限り早くお客さまにお届けすること。

そこを見誤ることはあってはならないので、今回は今の開発サイクルに合わせてよき改善ができたということです。
また、重大な障害は出ていないのですが軽微な障害はちょくちょく発生しています。

やっぱり品質に関わるものとしてそれを見逃すわけにはいかないので、リリース前のE2E自動テストとは別に詳細な自動テストを定期的に実行するよう、現在準備を進めています。

（ここで前述の消えていったテストコードが活かされそうです！よかった！）
他にも、現時点でリリース前のE2E自動テストはWebフロント側のページしか網羅しておらず、管理画面やモバイルアプリには自動テストが実装されていません。

こちらも逐次対応を進めていきます。がんばるぞ〜。
それでは！