本物のバグとフレーキーなテストを見分けるための開発者向けフレームワーク
Rui Li
テストが失敗しました。誰かに連絡したりチケットを起票したりする前に、判断が必要です。製品が実際に壊れているのか、それともテストが信頼性を欠いているのか。どちらの方向にせよこの判断を誤り続ければ、チームは本物のリグレッションをリリースするか、幽霊を追いかけて時間を無駄にするかのどちらかになります。
以下は、どちらの極端にも陥ることなく迅速にその判断を下すためのフレームワークです。
仮定ではなく、問いから始める
テストが失敗したとき、人は本能的にどちらかを決めつけようとします。「プロダクトに問題があるはずだ」、あるいは過去にフレーキーなテストに悩まされたチームであれば「おそらくフレーキーなだけだろう」と。どちらの直感も、実際の診断ステップを飛ばしています。
より適切な出発点は、もっと絞り込まれた問いです。テストがチェックしていた対象が、前回このテストがパスしたときと比べて異なる挙動をしたのか、それともテスト自体がプロダクトの挙動とは無関係な条件に遭遇したのか。この問いには明確な答えがあり、それを見つけるために推測は必要ありません。
本物の失敗とノイズを切り分ける4つの問い
テストのターゲットが、挙動の変化を伴わずに構造的に変更されたか？コンポーネントの名称変更、移動、またはスタイル変更が行われ、テストが古い構造に紐づいていた場合、プロダクトは意図どおりに動作していながらテストが失敗することがあります。これは、UIドリブンなテストにおける誤検知の最も一般的な原因です。
テストが通常のユーザーセッションとは異なる条件下で実行されたか？期限切れの認証情報、古くなったセッショントークン、テスト実行中に一時的な障害が発生したサードパーティの依存関係。これらはプロダクトのバグのように見える失敗を引き起こしますが、原因はプロダクトではなくテスト環境にあります。
失敗はオンデマンドで再現可能か？本物のリグレッションは、同じ手順を再試行すると一貫して失敗します。一方、レースコンディションや一時的なネットワーク障害による失敗は、2回目の試行では再現しないことが多いです。再現性のない失敗は、本物の挙動変化ではなく環境的な要因が関係している強いシグナルです（ただし、保証はありません）。
失敗は具体的かつ明確な不一致を示しているか？「ボタンのクリックが反応しなかった」という失敗は、タイミングやインタラクションの問題である可能性が高いです。一方、「合計金額が$45ではなく$38と表示された」という失敗は、再現方法にかかわらず調査が必要な実際の挙動の不一致を示しています。
このフレームワークが機能するために具体的な失敗情報が必要な理由
これら4つの問いのどれひとつとして、単純なパス・フェイルの結果だけでは答えられません。失敗が実際に何が起きたかを十分な詳細で説明し、期待される挙動や過去の実行結果と比較できるようにする必要があります。
ここで重要なのは、フレームワーク自体と同様に、テスト出力の質です。「assertion failed」とだけ報告するテスト失敗は、開発者が4つの問いを当てはめるための情報を何も提供しません。具体的なアクション、具体的な期待値、具体的な観測結果を説明する失敗であれば、開発者は数分で4つすべての問いに答えるために必要な情報を得られます。
TestSpriteのエクスプロレーションエージェントがこのレベルの詳細を生成できるのは、ソースコードに対してアサーションを行うのではなく、実際に動作しているアプリケーションを観察しているからです。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
シナリオ：ライブチケット販売プラットフォームにおける座席マップのソート順の失敗
ライブイベントチケット販売プラットフォームを開発するチームの開発者が、テストの失敗を受け取ります。会場レイアウトのレンダリングロジックに対する最近の変更後、座席マップビューで利用可能な座席が期待される順序で表示されていないというものです。
4つの問いを適用します。ターゲットが構造的に変更されたか？会場レイアウトコンポーネントが最近リファクタリングされており、テストが特定のDOM位置に紐づいていた場合、誤検知の原因として考えられます。テストが異常な条件下で実行されたか？いいえ、ビジネスアワー中に安定したプレビューデプロイメントに対して実行されており、認証情報や依存関係のカテゴリは除外されます。再現可能か？開発者が同じテストを再実行したところ、まったく同じ方法で再び失敗し、一時的な問題ではないことが示唆されます。失敗は具体的な内容を示しているか？レポートには、セクションCの座席がセクションDの後に表示されており、期待されるセクションのアルファベット順とは異なることが明記されています。
これは本物の、再現可能で具体的な挙動の不一致であり、ノイズではありません。開発者は、セクションの反復処理が変更され、元の3つ以降に追加されたセクションのソート順が意図せず逆転していたことを、最近の会場レイアウトリファクタリングにまで遡って特定します。コーディングエージェントが修正を適用し、再実行されたテストによって、新たに追加されたセクションを含むすべてのセクションで正しい順序が確認されます。
同じフレームワークを1週間後に同じプラットフォームの別の失敗に適用したところ、逆の結論が導き出されます。支払い確認テストが1回失敗しましたが、即座に再試行しても再現せず、失敗の説明はサードパーティ決済プロセッサのサンドボックス環境のレスポンス待ちのタイムアウトを指していました。これはリグレッションとして調査するのではなく環境的な問題としてフラグが立てられ、1時間後の2回目のスケジュール実行はクリーンにパスし、サンドボックスの障害が原因であったことが確認されました。
フレームワークを活用して時間の使い方を最適化する
4つの問いを実行することの価値は、すべての失敗を完璧に分類することではありません。チームが調査に費やす時間を、実際に調査する価値のある失敗に確実に向けることにあります。失敗の背後にある要因にかかわらず、すべての失敗に均等に注意を向けるのではなく。
TestSpriteのAuto-Heal Rerunを使用しているチームは、このトリアージの一部を自動化できます。明らかに挙動ではなく構造的な失敗はフラグを立てるのではなく適応されるため、フレームワークを手動で適用する必要があるのは、真に曖昧なケースのみとなります。
まとめ
すべてのテスト失敗が同じ対応を必要とするわけではありません。ターゲットが構造的に変更されたか、環境が通常と異なっていたか、失敗が再現するか、そして具体的な内容を示しているかという4つの具体的な問いを中心に構築されたフレームワークは、判断に頼るプロセスを、迅速で再現可能なプロセスへと変えます。
このプロセスが機能するのは、失敗レポートが十分な詳細を含んでいる場合に限ります。これは、コードから推測するのではなく、プロダクト層でテストを行うことが実際に提供するものです。
TestSpriteを試して、本物のバグとノイズを数時間ではなく数分で区別できるほど詳細な失敗レポートを入手しましょう。