【ITニュース解説】The Test Passed Until the Cookie Banner Showed Up

ソフトウェア開発において、作成したプログラムが正しく動くかを確認するために「テスト」は欠かせない。特に、WebサイトやWebアプリケーションの動作を確認するために、実際のユーザーのようにブラウザを操作して自動的に検証する「ブラウザ自動化テスト」は、現代の開発現場で広く使われている。しかし、このブラウザ自動化テストにおいて、近年、開発者を悩ませる特有の問題が増えている。

その代表的な例が「不安定なテスト」だ。テストを100回実行するとすべて成功するのに、なぜか101回目で突然失敗することがある。失敗したテストをすぐに再実行すると、また成功する、というような現象がそれだ。このような現象は単に「テストが不安定だ」と片付けられがちだが、実はその裏には、現代のWebアプリケーションが抱える複雑な事情が隠されている場合が多い。

テストが失敗する原因としてよくあるのが、突然現れる「クッキー同意バナー」だ。これは、Webサイトがユーザーのプライバシー保護のために、個人情報利用への同意を求める表示である。本来クリックしたいボタンが、テスト実行のタイミングでこの同意バナーによって覆い隠されてしまい、テストがボタンをクリックできずに失敗することがある。これは、特定の第三者サービスがウェブページに読み込まれ、ユーザーの同意を求めるバナーを表示したために起きる現象だ。

現代のWebアプリケーションは、もはやシンプルなHTML、CSS、JavaScriptだけで作られているわけではない。ユーザーが使うアプリケーション本体に加えて、広告表示のためのタグマネージャー、アクセス解析のためのアナリティクスツール、前述の同意管理ツール、チャットウィジェット、A/Bテストツール（異なるデザインを試すツール）、監視ツール、決済ウィジェット、新機能のオンオフを切り替える機能フラグなど、非常に多くの「第三者コード」が組み込まれている。これらのコードは、いつ、どの順番で、何が表示されるかがテストからは予測しにくい。そのため、テスト実行ごとにページの状態が微妙に異なり、テストが不安定になる根本的な原因となる。

また、「ページの読み込みが完了した」という概念も、以前とは大きく変化した。かつては、ブラウザがページの読み込みを終えれば、すぐにテストを続行しても問題ないとされていた。しかし今日では、ブラウザが基本的なページの読み込みを終えた後も、アプリケーション内部では様々な処理が進行している。例えば、ページが表示されても、JavaScriptフレームワークの初期化（Reactのハイドレーションなど）、新機能の有効/無効を決定する情報の取得、リアルタイム通信のためのWebSocket接続、ユーザー情報の受信、ダッシュボードの更新、通知の表示など、ユーザーにとって本当に重要な情報が表示されるまでに時間がかかる場合がある。テストがどのタイミングで「ページが完全に準備できた」と判断し、次の操作に進むべきかは、一概には言えない複雑な問題になっている。

特に、WebSocketを使ったリアルタイムなアプリケーションでは、この問題が顕著になる。WebSocketは、サーバーとブラウザ間で常に接続を維持し、リアルタイムにデータを送受信するための技術だ。例えば、注文状況を表示するダッシュボードのテストを考えてみよう。最初は「注文数：17」と表示されていたが、新しい注文があったことをWebSocketを通じて受信すると、UIが「注文数：18」に更新される。これは単純に見えるが、もしWebSocketが一時的に切断された後に再接続され、複数の更新メッセージが連続で届くような状況ではどうなるだろうか。UIが更新されている途中でテストが情報を確認しようとすると、期待する値とは異なる状態を読み取ってしまう可能性がある。結果として、テストは失敗するが、それがアプリケーションのバグなのか、テストの実行タイミングの問題なのかを判断するのが非常に難しい状況が生まれる。

こうした複雑な原因でテストが失敗した場合、「テスト失敗」という一言だけでは、開発者は問題解決のために何もできない。問題解決のためには、失敗した瞬間の詳細な情報が不可欠だ。具体的には、失敗直前のスクリーンショットと失敗時のスクリーンショット、その時点でのWebページの構造（DOMスナップショット）、ブラウザのコンソールに表示されたログ、ネットワークを通じて行われた通信の記録、使用されたブラウザのバージョン、テストがそこに至るまでの操作履歴、そして失敗した時刻、可能であればテスト実行時の動画記録など、多角的な「証拠」（エビデンス）が必要となる。これらの情報が豊富にあれば、開発者は「何が起きたのか」を正確に把握し、迅速に問題の原因を特定できるようになる。

テストツールの評価においても、新しい視点が求められている。これまではテストの作成速度や実行速度、並列実行の効率性などが重視されてきた。しかし、これからは「テストが失敗した際、その原因をどれだけ早く理解できるか」という「障害理解までの時間」も重要な指標となるべきだ。たとえテストの実行に時間がかかっても、失敗した時にたった5分で原因を突き止められるツールと、実行は速いが原因解明に25分もかかるツールでは、結果として後者のほうが開発コストが高くつく可能性があるのだ。

人工知能（AI）の進化により、テストの作成コストは大幅に下がっている。AIがより多くのテストを自動生成できるようになれば、組織が抱えるテストの数も飛躍的に増加するだろう。しかし、テストの数が増えれば、それに比例して失敗する回数も増えることになる。AIはテスト作成のボトルネックを解消するが、その代わり、増えた失敗の調査と管理という新たな課題を生み出すのだ。 AIによるテストの「自動修復」機能にも注意が必要である。例えば、「アカウントを削除」というボタンをクリックするテストが、UIの変更でボタンの識別情報が変わり失敗したとする。AIがこれを自動修復し、近くにあった「アカウントを一時停止」というボタンに置き換えてテストをパスさせてしまったらどうなるだろうか。テストは成功したと表示されるが、実際には意図しない操作が行われており、重大なバグを見逃してしまうことになる。「テスト失敗」は「何かが変わった」という警告だが、「誤って修復されたテストの成功」は「すべて問題ない」という誤った安心感を与え、かえって危険である。自動修復は、何が、なぜ、どのように変更されたのかを明確に提示し、開発者がその修復をレビューし、承認または拒否できる仕組みが不可欠だ。

したがって、どのテストツールを選ぶべきかという問いも、「最高のツールは何か」ではなく、「私たちの組織にとって最適なツールは何か」という視点に変わる。単に機能リストを比較するだけでは不十分で、各組織の具体的なニーズ（例えば、素早いテスト作成を重視するのか、あるいは厳格な品質管理プロセスを重視するのか）に合わせて、ツールのメリットとデメリットを比較検討する必要がある。

ベンダーからテストツールを評価する際には、あえて「意図的に複雑な状況を作り出すテスト」を試すべきだ。例えば、認証が必要なアプリケーションを開き、同意バナーを表示させ、外部ウィジェットを読み込み、WebSocketに接続してリアルタイムなUI更新を発生させ、さらにネットワーク状態を変更してWebSocketを切断・再接続させ、意図的にレイアウトを変更して最後にテストを失敗させる。このような複雑なシナリオをテストツールで実行し、その結果をテストを作成していない第三者に見せて、「何が壊れたのか」を5分以内に自信を持って答えられるかを問う。もし「要素が操作できない」という抽象的なエラーメッセージを30分も眺めるような結果であれば、AIによる自動テストのデモがどれほど素晴らしくても、そのツールは実用性が低いと判断すべきだ。

テスト自動化におけるこれまでの課題は、テストの作成に時間とコストがかかりすぎることだった。AIはこのボトルネックを解消しつつある。しかし、一つのボトルネックが解消されると、次のボトルネックが姿を現すのが常である。これからの課題は、「より多くのテスト → より多くの実行 → より多くの失敗 → より多くの証拠 → より多くの人間の判断」という連鎖から生まれる、失敗の理解と対処にかかる負荷だ。 最終的にテストが提供する価値は、テストダッシュボードに表示される「すべてパス」という緑色の表示でも、テストコードそのものでもない。それは、「確信」である。そして、その確信は、「何か失敗した」という事実を知ることからではなく、「なぜ失敗したのか」を明確に理解することから生まれる。だからこそ、テストの失敗をいかに速く、正確に理解できるかが、今後のテスト自動化ツールの真価を測る重要な基準となるだろう。