フレイキーテスト：原因と根本的な解決策
Yunhao Jiao
フレイキーテストは、あらゆる自動テストプログラムに静かなコストをもたらします。断続的に失敗し、リトライすると通過し、エンジニアリングチームに二択を迫ります——おそらく実在しない失敗の調査に時間を費やすか、あるいは無視して本当の失敗を見逃すリスクを取るか。
ほとんどのチームは結局両方を行い、どちらも一貫性がありません。その結果、エンジニアが信頼できなくなったCIパイプラインと、蓄積されたノイズによって有用性をほぼ失った品質シグナルが残されます。
このガイドでは、フレイキーテストの原因、体系的な診断方法、そして症状を取り繕うのではなく根本原因を排除するモダンなAIテストアプローチについて解説します。
フレイキーテストとは何か？
フレイキーテストとは、同一のコードに対して実行するたびに結果が一定しない——合格したり失敗したりする——自動テストのことです。テストの失敗はアプリケーションの実際のバグによるものではなく、テスト自体の問題——タイミングの問題、環境依存、共有状態、またはテスト実行における非決定性——に起因します。
フレイキーテストは、正当に失敗するテストとは異なります。正当な失敗はアプリケーションにバグがあることを意味します。フレイキーテストの失敗はテスト自体にバグがあることを意味します——より一般的には、タイミング・状態・環境に関してテストが立てている仮定が確実に正しいとは言えないケースです。
フレイキーテストが見た目以上に深刻なダメージをもたらす理由
フレイキーテストの明らかなコストは、CIパイプラインの再実行や誤検知の調査に費やされる時間です。これは現実の問題であり——チームはフレイキーテストのノイズ対応に毎週数時間を無駄にすることがあります——しかしそれが最も深刻な問題ではありません。
より根深い問題はシグナルの劣化です。CIパイプラインが十分な頻度でレッドになると、エンジニアはレッドを意味あるものとして扱わなくなります。まずリトライし、あとで調査し、リトライが通ればマージする、という習慣が生まれます。「おそらくフレイキーだろう」という文化は、本物の失敗も見過ごされることを意味します。リグレッションがマージされます。バグがリリースされます。
チームが一度テストスイートへの信頼を失うと、その信頼を回復するには多大な労力が必要になります——根本的なフレイキーネスを修正するよりもはるかに大きな労力が。
フレイキーテストの7つの根本原因
1. タイミングと競合状態
フレイキーテストの最も一般的な原因です。テストが準備の整っていない要素やAPIにアクセスしてしまう——レンダリングが完了していないボタン、まだ返ってきていないAPIレスポンス、完了していないアニメーションなど。固定待機（sleep(2000)）は信頼性が低く遅いという点で事態を悪化させます。正しい修正方法は、アプリケーションの実際の状態を監視するアダプティブウェイトです。
兆候：低速なマシンでは通過し、高速なマシンでは失敗する。ローカルでは通過し、CIでは失敗する。パフォーマンス最適化後から失敗し始める。
2. テスト間の共有状態
テストBがテストAによって作成された状態に依存している。テストの実行順序が変わったり、テストAがスキップされたりすると、テストBはテスト対象のコードとは無関係な理由で失敗します。テストは完全に独立している必要があります——各テストが自身の状態を作成し、テスト後にクリーンアップを行います。
兆候：テストを単独で実行すると通過するが、フルスイートの一部として実行すると失敗する。他にどのテストが実行されるかによって失敗内容が変わる。
3. 外部依存
サードパーティAPI、データベース、または外部サービスへの実際のネットワーク呼び出しを行うテストは、それらのサービスが遅い・レート制限されている・一時的に利用不可の場合に失敗します。これらの失敗はアプリケーションの失敗ではなく、環境の失敗です。
兆候：特定の時間帯に失敗が増加する。失敗メッセージにネットワークタイムアウトや429レートリミットレスポンスが含まれる。
4. 環境の不一致
ある环境では通過し、別の環境では失敗する——Nodeのバージョンの違い、タイムゾーン設定の違い、データベースのシーディングの違い、環境変数の違い。テストが普遍的に正しいとは言えない環境に関する仮定を立てています。
兆候：ローカルでは通過し、CIでは失敗する。あるエンジニアのマシンでは通過し、別のエンジニアのマシンでは失敗する。
5. 壊れやすいロケーター
CSSセレクターやXPath式を使用するUIテストは、DOMが変更されると失敗します——変更が見た目上のものであり機能に影響しない場合でも。開発者がクラス名を変更したり、フレームワークの更新でレンダリングされるHTML構造が変わったり、デザインシステムのトークンによってコンポーネントのマークアップが変わったりする場合も含みます。
兆候：ユーザー向けの動作を変更しないUIリファクタリングの後にテストが壊れる。同じコンポーネントを中心に失敗が繰り返し発生する。
6. 実行順序に対するテストの相互依存
共有状態と関連していますが、特にテストの順序に関するものです。一部のテストランナーはテストを実行するたびに異なる順序で実行し、順序に関する暗黙的な仮定を持って書かれたテストは順序が変わるとフレイキーになります。
兆候：コードが変更されていないにもかかわらず、実行のたびにテストの失敗内容が変わる。特定のテストが常に一緒に失敗する。
7. アプリケーションの非決定的な動作
アプリケーション自体が同じ入力に対して異なる出力を生成する——ランダムなID、タイムスタンプ、確率的なAI出力、ランダム化されたソート順など。これらの出力に対してアサートするテストは、正確な値ではなく意図をテストしない限りフレイキーになります。
兆候：テストがタイムスタンプ、生成されたID、またはその他の可変出力を含む正確な値に対してアサートしている。
フレイキーテストの診断方法
ステップ1：無視せず隔離する。フレイキーテストに個別のタグを付ける——既知のフレイキーテストとしてマークし、CIのブロック対象から除外します。こうすることで、根本原因を修正する間もシグナルの劣化を防げます。削除するのは誤りです——フレイキーテストは実際の機能をカバーしていることが多いからです。
ステップ2：フレイキーテストを単独で繰り返し実行する。安定したコードベースに対して、問題のあるテストを20〜50回実行します。これにより、実際にフレイキーであることを確認し、失敗率のデータを取得できます。
ステップ3：実行間で何が変化しているかを調べる。タイミング？テストの順序？環境？失敗メッセージには通常、手がかりが含まれている。ネットワークタイムアウトは外部依存関係の問題を示す。要素が見つからないはタイミングまたはロケーターの問題を示す。状態の不一致は共有状態の問題を示す。
ステップ4：個別のインスタンスではなく、カテゴリそのものを修正する。sleepを追加して単一のフレイキーテストを修正するのは間違ったアプローチだ。問題のカテゴリを修正すること——アダプティブウェイトを体系的に使用し、状態を体系的に分離し、外部依存関係を体系的にモックする。
AIテストツールがフレイキーネスを根本から排除する方法
従来の自動テストでは、上記のすべての修正をエンジニアが手動で実装する必要がある——アダプティブウェイトの記述、状態の分離、依存関係の正確なモックなど。これは手間がかかり、エラーが発生しやすい作業だ。
TestSpriteのようなモダンなAIテストツールは、フレイキーネスをアーキテクチャレベルで解決する：
インテントベースのロケーターが、壊れやすいCSSセレクターに取って代わる。cy.get('.submit-btn-v3')の代わりに、AIが実行時に「プライマリフォーム送信ボタン」をセマンティックにマッチングする。マークアップが変更されてもインテントは有効なままであるため、UIのリファクタリングによってテストが壊れることはない。
インテリジェントな失敗分類が、テストの脆弱性と本物のバグを自動的に区別する。テストが失敗した場合、TestSpriteのエンジンはその失敗が本物のアプリケーションバグなのか、タイミングやロケーターの問題なのか、環境の問題なのかを判断し、それぞれに適切に対処する。本物のバグは実用的なレポートとして表面化され、脆弱性は自動修復される。
分離されたクラウドサンドボックスが、環境の不整合を完全に排除する。すべてのテスト実行は既知のクリーンな状態から開始される。共有データベースなし、前回の実行による残留状態なし、ローカル環境の差異なし。
アダプティブ実行が、固定ウェイトなしでタイミングやレースコンディションに対処する。TestSpriteは各テストステップを実行する前に、DOMの安定性、ネットワークのアイドル状態、アニメーションの完了など、実際のページ状態を監視する。
実際の成果として、TestSpriteを使用するチームは劇的にフレイキーネス率が低下したと報告している。これはAIテストエンジンがフレイキーネスの根本原因を単に検出して再試行するのではなく、最初から回避するよう設計されているためだ。
フレイキーネスのない文化を構築する
ツールの活用に加えて、フレイキーテストへの対処においてチームにとって最も重要なことは、それを本物のバグとして扱うことだ。フレイキーテストはテストスイートの欠陥であり、許容できる煩わしさではない。本番バグと同じ注意——トリアージ、根本原因分析、そして恒久的な修正——に値する。
この基準を一貫して維持するチームは、エンジニアが信頼できるテストスイートを持つ——そしてエンジニアが信頼するテストスイートは、リグレッションを確実に捉える。
TestSpriteでフレイキーネスのないテストスイートの構築を始める →