ネイティブE2Eテストの信頼性を高める壊れたテストの修正だけに頼らないアプローチ

エンドツーエンド(E2E)テストは、Android や iOS といった複数のプラットフォーム、さまざまな画面サイズ、OS バージョンで動作するネイティブアプリケーションにとって特に重要です。E2Eテストは、このように断片化されたエコシステム全体における動作の違いを検出することができます。

しかし、E2E テストの信頼性を維持することは、テストを書くこと自体よりも難しい場合が少なくありません。 

断片化したデバイス環境、テストフレームワークの不足、ネットワークの不安定さ、不安定なテスト環境、そして頻繁に変わる UI。これらすべてが、テストが不安定になる原因になります。その結果、多くのチームは UI の変更や環境の不安定さによって壊れたテストを修正し続けるループに陥りがちです。本来取り組むべきテスト基盤全体の信頼性向上ではなく、失敗したテストの対応に追われてしまうのです。やがてチームはフラストレーションを感じ、ワークフローにE2Eテストを導入すること自体に慎重になってしまいます。

私自身、中規模企業でネイティブ E2E テスト基盤の構築を主導する中で、長期的なテストの安定性を維持するには、テストの責任範囲（ownership）、可観測性（observability）、通知の仕組みをしっかり設計・実装することがいかに重要かを身をもって学びました。この記事では、これまでにチームが直面してきた課題を紹介しながら、本当に信頼できるE2Eテスト基盤を構築するための考え方と実践を共有します。

リアクティブなテスト保守が抱える課題

CI 上で定期的にE2Eテストを実行する仕組みを整えた当初、私たちのチームはテストの安定性を高めるために、失敗したテストのトリアージ、調査、修正に注力しました。しかし、不安定なテストをほぼ 1 年近く修正し続けても、E2Eテストスイートの信頼性はほとんど改善しませんでした。そしてエンジニアたちは次第に、このテストスイートの有用性や信頼性そのものに疑問を持つようになっていきました。

壊れたテストの修正ばかりに集中してしまうチームは、不安定さの根本原因を解決しないまま、失敗を追い続けるループに陥りがちです。このような受動的なアプローチは、いくつもの問題を引き起こします。

• テストスイートの脆弱性:アプリ側の変更や不安定なテスト環境といった本当の原因に対処しないまま壊れたテストの修正だけを続けていると、テストスイートは次第に脆くなっていきます。時間が経つにつれて、実際の製品不具合とは関係のない理由でテストが失敗するようになり、本当の回帰（regression）とノイズを見分けることが難しくなります。
• 高いメンテナンスコスト: 不安定なテストのデバッグや修正には、多くの開発者の時間とリソースが必要になります。ユニットテストは高速に実行され、問題も個別に切り分けやすいのに対し、E2Eテストは 開発環境、ステージング環境、またはプレプロダクション環境を対象に実行されるため、失敗の再現や原因特定が難しくなります。さらに、異なる画面サイズや OS バージョンを持つデバイスでE2Eテストを実施するには、追加の調整が必要になり、修正作業は決して簡単ではありません。
• テストスイートへの信頼低下: テストの失敗が頻繁に発生しノイズが多くなると、チームはE2Eテストスイートへの信頼を失い、失敗を無視するようになってしまいます。これは、本来の自動テストの目的そのものを損なうことになります。その結果、変更の検証はローカルでの開発テストや手動 QA に頼るようになり、時間が経つにつれてテストスイートは品質を守る仕組みではなく、むしろ開発を遅らせる負担になってしまいます。

E2Eテストを **問題が起きるたびに修正する“受動的な運用”**では、リリースサイクルは次第に遅くなります。開発者は失敗したテストの修正と再実行に多くの時間を費やすことになり、本来検出すべき回帰バグは 手動 QA に頼って見つける状態になってしまいます。

信頼できるE2Eテスト基盤の構築

テストスイートの安定性が1年以上失敗を追いかけても改善しなかったため、私たちは一歩引いて過去の結果を分析し、パターンを探しました。 

多くの障害は不安定な環境やテストアカウントの予期せぬ状態に起因することが判明しました。例えば、テスト環境でのAPI遅延の急増は誤陰性を引き起こし、ノイズを増幅させました。同様に、既存のユーザーアカウントに対してテストを行う場合、過去の失敗や複数のテストが同じアカウントを使おうとした場合に不整合になることがあります。

テストインフラの改善に投資することが、安定し信頼できるネイティブE2Eテストワークフローを実現する唯一の方法だと学びました。これには、テスト環境の安定化、明確なテスト所有権の定義、ノイズの多いアラートの削減、観察可能性の向上が含まれます。これらをそれぞれ詳しく見ていきましょう。

試験環境の安定化

多くの不安定なE2Eテストは、機器の断続的な問題、ネットワークの不安定さ、ステージング環境でのAPIダウンなど、基盤環境の不整合に起因します。 

ノイズが多く信頼性の低いテストを避けるために、以下のテスト実践を用いて安定し標準化されたテスト環境を確保してください。

• デバイスと環境の設定を標準化する: デバイスおよび試験環境の安定性問題は、試験の安定性に大きな影響を与えます。APIのダウンタイムを減らすために、不安定なビルドや実験機能による干渉を防ぐために、E2Eテスト環境を開発者やステージング環境から隔離してください。チームは、本番対応のアーティファクトを使った安定した事前本番環境を構築するか、E2E実行ごとに一時的な環境を立ち上げて一貫性を確保することができます。標準化されたデバイスイメージやコンテナ化されたエミュレーターで、OSのバージョン、設定、リソースが一貫した上でテストを行うことで、安定性がさらに向上します。重要なフローについては、物理デバイスファームで定期的に実行をスケジュールし、実際のハードウェアと照合して検証しつつ、日々のテストを安定かつコスト効率よく保つことができます。
• セッションごとのテストデータの分離: データに修正を加えるテストは、白紙の状態から始めるべきです。例えば、todoアプリケーションのテスト中は、予測不能なアカウント状態による予期せぬシナリオを避けるために、すべてのテストセッションごとに新しいテストアカウントを使うべきです。テストを高速化するために、『ビフォー』フックでセットアップスクリプトを実行してアカウント作成を処理し、必要なデータを自動でシードします。
• 特定のネットワークの反応を嘲笑する: E2Eテストは実際のデータを使ってユーザージャーニー全体をテストすることを目的としていますが、場合によっては予測可能なテスト環境を維持するために特定のAPI応答をモックする必要があることもあります。例えば、アプリケーションがA/Bテストに依存したり、機能フラグを使用している場合、異なるセッションはユーザー割り当てに応じて異なる体験を受けることがあります。これにより、実際の回帰とは無関係な予期せぬ故障が発生することがあります。テストビルドでこれらの応答をモックすることで、セッション間の一貫性を確保し、異なるユーザー体験を扱う複雑なテストケースの構築を避けられます。

明確なテスト所有権の確立

テストが失敗すると、誰が調査し修正する責任があるのかが不明瞭になることが多いです。時間が経つにつれて、明確なテスト所有権や責任の欠如が、信頼性を欠き、メンテナンスも行われず、不安定なテストを生み出します。 

製品機能の所有権に基づいてテストの所有権を割り当てることで、この問題をある程度緩和できます。理想的には、所有チームが重要なフローのテストの作成、保守、修正を担当すべきです。この所有モデルにより、故障は迅速にトリアージされ、製品の進化に合わせてテストが更新され、古臭く不安定になることがありません。 

複数のプロダクトチームが単一のユーザーフローの一部を所有するコードベースでは、テストの所有権が難しくなります。例えば、ショッピングアプリケーションでは、異なるチームがログイン、商品カタログ、レジ体験を所有している場合があります。ログインステップでチェックアウトフローテストが失敗すると、どのチームがトリアージすべきか混乱しやすくなります。明確な方針がなければ、失敗が無視されたり、複数のチームが重複作業を行ったりする可能性があります。 

これらのシナリオに対応するために、エンドユーザー体験に基づいてテストごとに最初の接触点(POC)を定義するポリシーを設定します。これにより、単一のチームが問題のトリアージを担当しつつ、必要に応じて上流の依存関係に修正を委ねることができます。

ノイズを減らし、アラート機能を向上させる

ネイティブのE2Eテストでよくある課題は、不安定または失敗したテストによるノイズの多いアラートです。一時的なネットワークやデバイスの問題で不安定なテストが失敗すると、チームはしばしば実行に移らないアラートで溢れかえます。既知のバグに関する繰り返しの失敗通知もアラート疲労の原因となります。

以下の技術はこのノイズを軽減し、実行可能な故障時のみチームに通知を行います。

• 不安定なテストと既知のバグ: すべてのテスト失敗をチームに報告・通知する代わりに、不安定または既知の問題に関連するテストからのアラートをコード変更なしでミュート化できるようにしましょう。ミュートテストはリモート設定や環境変数、または BrowserStackのようなツールで管理できます。フォローアップのためにフラグを立て、アラートは新規または予期せぬ回帰のみに行わせてください。ミュートは特にE2Eテストで重要です。なぜなら、失敗したテストを修正するには開発者の時間とリソースが多大な必要があるからです。繰り返されるアラートは特に開発者にとって気が散ることがあります。
• 故障の詳細を通知に充実させる: 一般的な失敗メッセージの代わりに、失敗したユーザーフロー、コミット詳細、エラーメッセージ、ログやダッシュボードへのリンクなどの詳細をアラートに含めましょう。これらの詳細により、開発者は問題をより早く特定・トリアージし、より迅速な修正とスイートへの信頼度向上につながります。
• テストの指標や傾向を追跡する: テストスイートレベルのレポートに加え、テストの過去の結果を追跡・分析することで、失敗率、不安定さの傾向、故障ホットスポットを理解しましょう。例えば、ログインフローで繰り返し失敗が見られる場合、それは不安定なテストや散発的なバグの兆候かもしれません。これらの指標を時間をかけて追跡することで、Eスイート2Eスイートが改善しているか劣化しているかを可視化し、影響に基づいて安定化の優先順位をつけるのに役立ちます。

Docker化されたエミュレーターを用いたE2Eのスケーリングのハイブリッド戦略

ネイティブのE2E検査を大規模に実施することは、コストとリソースの制約から困難です。実際のクラウドベースのデバイスへのアクセスを提供するデバイスファームは、大量のテストを高頻度で実行するには高コストです。これは、変更がマージされる前のすべてのプルリクエストで実行されるCIパイプラインとE2テストを統合する制約となります。 

前述の通り、Docker化されたエミュレーターをPRビルドに使うハイブリッドテストアプローチと、定期的な実行を行う実際のデバイスを使うことで、この課題を克服できます。私たちのチームがPRチェックをDocker化されたエミュレーターに移行したことで、より速いフィードバックが得られ、クラウドデバイスのコストを大幅に削減しました。

コンテナ化されたデバイスランナーはCIで迅速に立ち上げることができます。例えば、 docker-android イメージはコンテナ化されたDocker環境でAndroidエミュレーターを動かすことができます。複数のデバイスプロファイル、OSバージョン、AppiumやEspressoなどのUIテストフレームワークをサポートしています。チームはこれらのエミュレーターをCIパイプラインに簡単に統合し、大規模なテスト予算を投じることなくE2Eテストを大規模に実行できます

モバイルウェブ向けにE2Eテストを構築する場合、 コンテナ化されたブラウザイメージ を使って異なる環境で一貫してテストを実行することで、コストや設定の複雑さをさらに削減できます。

希望はある!

もしチームが私たちのようにネイティブのE2Eテストの失敗を追いかけてきたなら、テストの安定性を向上させることなく、エンジニアリングの時間とリソースを無駄にしている可能性が高いです。この記事が、テスト環境、デバイス設定、アラート、観察可能性の改善というより良い方法があることをあなたに励ましにしたことを願っています。 

まずは過去のテスト失敗を分析し、それらをバケットに分類することが最善の第一歩です。これらの洞察を活かして、不安定さを減らすための実行可能な項目を定義しましょう。このロードマップを使って、最も効果をもたらすテストインフラ投資やプロセス変更を特定しましょう。 

私たちのチームがテストインフラの改善に投資した後、安定性が明確に向上しました。開発者は実際の故障をよりよく理解できるようになり、ノイズの多い警告の数も減りました。不安定さは完全に消えませんでしたが、テストスイートの信頼性向上により、本番環境にリリースされる前に複数のネイティブアプリ回帰を発見することができました。

この記事があなたも同様の勝利を収める助けになれば幸いです。