E2Eテストは「作成当時の再現性」の塊でできている

＼オカウチワニが1人でやっている okauchiwani-hitori Advent Calendar 2025 4日目の記事です!!!／

なぜE2Eテストのメンテは地獄化するのか

E2Eテストの運用がつらくなる理由はシンプルで、「現実のアプリケーションはどんどん進化するのに、E2Eテストはそれ以前の世界を前提にしている」からです。たとえば、次のような変化があるだけでテストはもろくなります。

• UIの文言が微妙に変わる
• APIのレスポンス形式が微妙に変わる
• データが足りず、期待する画面に遷移しない

ひとつひとつの変化は小さいのに、それらが組み合わさってテストが通ったり通らなかったりする謎の揺らぎを生む。その結果、開発者もQAエンジニアも「なんか flaky（不安定）だね」と呟きながらスクリーンショットとログとにらめっこする毎日が始まります。

そしてもっと厄介なのは、E2Eテストが落ちたとき、

• 仕様変更のせいで落ちているのか
• アプリが不安定なのか
• テストシナリオが悪いのか
• テストデータの問題なのか

E2Eテストは一気通貫でテストを行い、どこか1つでもおかしくなってしまった時点で失敗してしまいます。これがE2Eテストのメンテを地獄化させる最大の原因です。

再現性が崩れるポイントはどこに潜んでいるのか

再現性が崩れるポイントは、大きく分けると3つあります。

1. UIの揺らぎ

UIの揺らぎはE2Eテストの最大の敵です。

• ボタン名が微妙に変わった
• 表示順がデバイス依存で変わる
• ローディングアニメーションが長引く

こういった小さな差が再現性を一気に壊します。「昨日は動いたのに」という現象は大体UIの揺らぎです。「ボタン名の表現をより柔らかくしました」と言うような軽微でユーザーフレンドリーな変更しても、完全な文言一致でE2Eテストが動いているようならば失敗してしまいそうですね。

2. データの揺らぎ

テストデータは常に劣化します。データが足りなかったり古かったり、想定外の状態になっていると、
正しい画面に辿り着かないという悲しい現象が起きます。またデータの作成上限にひっかかってしまい、作成に失敗、テストも失敗するということもありえます。

• 在庫切れで遷移すべき画面が出ない
• ログインユーザーがBAN状態だった
• テスト環境で商品が勝手に削除されていた

自分では気づかないうちに、前提条件がズレていくのがこの領域です。

3. サーバーレスポンスの揺らぎ

バックエンドも常に変化しています。E2Eテストはサーバーの状態に強く依存するため、レスポンス時間やAPIの値が変わるだけでも破綻します。

• E2Eテスト関係のないサーバー負荷によってタイムアウトが出る
• キャッシュの有無で挙動が変わる
• バッチ処理のタイミングでデータが更新される

このあたりの揺らぎを無視すると、再現性は一気に崩れます。

E2Eテストを安定させるには「前提条件」を整えるしかない

E2Eテストの品質は、どれだけ前提条件を安定させられるかに集約されます。

• データを毎回初期化する
• APIで判定できる部分はAPIを利用する
• ローディング待ちは「時間」ではなく「状態」で確認する
• ページ遷移の“完了条件”をちゃんと定義する
• テスト環境をなるべく固定する

こういった工夫が積み重なるほど、「再現性の揺らぎ」が減っていきます。テストシナリオとして抑えることも出来れば、開発者に協力を仰がないといけないものもあります。運用の仕組みごと一緒に設計していくことで、初めて再現性のある自動テストになるので、テストが失敗したときにすぐ原因を特定できるよう、ログや画面キャプチャ、APIのレスポンスなどをモニタリングする仕組みを整えておくのも効果的です。

まとめ

E2Eテストは、華やかに見えて実は"再現性の塊"でできています。

• UI、データ、サーバーレスポンスの揺らぎがメンテ地獄の原因
• 再現性が崩れるポイントを知っておくと修正が早くなる
• 安定させるには、とにかく前提条件を整えるしかない

この"再現性"とどう付き合っていくかが、E2Eテストの生産性と成果を左右します。1段ずつレベルアップをするように進めていきましょう！