TestSpriteのAuto-Heal Rerunはどのように機能するか
Rui Li
テストの失敗は常に一つの問いを投げかけます。製品が壊れたのか、それともテストが陳腐化したのか。
その答えを出すには熟練した判断が必要です。経験豊富なQAエンジニアは、失敗したテストを確認し、製品を実際に開いてフローを手動で試した上で判断を下します。ボタンの位置が変わったがチェックアウトは機能しているのであればテストを更新すべき、あるいはボタンの位置が変わりチェックアウトも本当に壊れているのであれば製品を修正すべき、といった具合です。その的確な判断こそが、テストスイートを意味あるものに保ちます。
Auto-Heal Rerunは、TestSpriteがすべての失敗に対して自動的にその判断を行い、結果があなたに届く前に処理を完了させる仕組みです。その内部で実際に何が起きているかを解説します。
トリガーの条件
Standardプラン以上で利用可能なAuto-Heal Rerunは、テストが失敗したときに作動します。すべての実行で発動するわけでも、包括的なリトライポリシーとして機能するわけでもありません。以前は正常に動作していたテストが合格しなくなった状況に特化して応答します。
この状況には2つの原因が考えられ、それぞれ正反対の対応が求められます。製品がリグレッションを起こした場合、失敗は即座に明確に報告されなければなりません。UIが単に変化した場合、コンポーネントのリネーム、レイアウトの再編成、要素の移動などであれば、その失敗はノイズであり、報告することでエンジニアが「製品は正常だった」という結論の調査に時間を費やすことになります。
Auto-Heal Rerunの設計全体は、この2つのケースを同一視しないことを目的としています。
判断基準：構造ではなく動作
テストが失敗した際、エージェントが問うのは「要素を再び見つけられるか」ではありません。QAエンジニアが問うであろう問い、「製品はユーザーに正しい結果を提供できているか」を問います。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
エージェントは実際のユーザーと同様に、実行中のアプリケーション上でフローを再実行します。送信ボタンがリネームされスタイルが変わっても、ユーザーがフォームを入力して送信を完了できるなら、動作は維持されています。失敗は構造的なものです。テストは変化したUIに適応し、リランが完了し、重要な事実が報告されます。フローは正常です。
ユーザーがフローを完了できない場合、フォームが送信先なしで実行される、確認画面が表示されない、結果が不正であれば、動作がリグレッションしています。実際の障害を隠蔽することになるため、適応は行われません。失敗は製品レベルの説明とともに報告されます。実行したアクション、期待される結果、実際に発生したことが明示されます。
名称の「Rerun（再実行）」は文字通りの意味です。適応されたテストが再実行されるため、ヒールは仮定ではありません。現在のUIに対して合格が検証された結果です。
Auto-Healが明示的に行わないこと
「セルフヒーリング」という言葉は業界で広く使われているため、一点明確にしておく必要があります。Auto-Heal Rerunは、UIのずれやレイアウト変更に対してテストを適応させます。アプリケーションコードを書き換えることはありません。
動作が本当に壊れている場合、Auto-Healは修正を試みず、リグレッションを回避するパッチを当てず、製品がどうあるべきかを独自に判断することもありません。報告するだけです。修正はあなたのワークフローに委ねられます。失敗の詳細はMCP Serverを通じてIDEに返され、コードを書いたコーディングエージェントがあなたの関与のもとで修正案を提示します。
テストの修正と製品の修正は別の作業であり、両者を分離しておくことが、グリーンの信頼性を担保します。本物のリグレッションに自ら適応してしまうテストスイートは、スイートがまったくない状態よりも有害です。
AIコーディングチームにとって特に重要な理由
構造的なずれはかつてまれな出来事でした。AIコーディングツールの登場により、それは日常的なものとなりました。
Cursorのセッションがパフォーマンス改善の副作用としてコンポーネントツリーを再構成する。Claude Codeのセッションがフックを統合する際に要素をリネームする。いずれもユーザー体験には影響しませんが、構造に依存したテストはすべて壊れます。1日に複数のセッションを実行するチームにとって、動作を判断できないスイートは常に失敗し、その都度エンジニアが「問題なし」と確認する作業が生じます。
この計算がテストの存続を左右します。10件の失敗のうち9件が構造的なノイズであれば、エンジニアは失敗を読まなくなり、10件目の本物のリグレッションがリリースされます。Auto-Heal Rerunはこの計算を変えます。構造的なずれはサイレントかつ検証可能な形でヒールされるため、チームに届く失敗はすべて対処する価値のあるものになります。スイートは、それなしでは崩壊していたほどの変更ペースに、確実に追従し続けます。
シナリオ：1回の失敗、同一実行内での2つの経路
あるチームがClaude Codeを使って非営利団体の寄付プラットフォームを構築しています。セッションで寄付フォームが刷新され、金額ボタンがスライダーコンポーネントに変わり、レイアウトが変更され、定期寄付のトグルがリネームされてオプションパネルに移動しました。
夜間実行が変更されたフォームに到達し、寄付フローのテストが初回実行で失敗します。Auto-Heal Rerunが起動します。
エージェントは実際の寄付者として新しいフォームを操作します。スライダーで金額を設定し、オプションパネルを開き、定期寄付を有効にして送信します。フローは完了し、確認画面には正しい金額と頻度が表示され、サンクスメールも送信されました。動作は正常です。テストは新しい構造に適応し、再実行はパスします。翌朝のレポートには、誤検知のアラートではなく、寄付フローがグリーンであること、そしてヒールが行われた旨が記録されます。
同じ実行でレシートダウンロードのテストも失敗し、ここで2つ目の経路が展開されます。エージェントはフローを再試行します。寄付を完了し、レシートを開きます。レシートは表示されますが、寄付金額が$0.00と表示されています。刷新されたフォームがスライダーの値をセント単位で渡すようになったのに対し、レシートテンプレートがドル単位でフォーマットしたまま、すでに除算された数値をさらに除算しているためです。動作が壊れています。適応は行いません。どのフロー、レシートに何が表示されたか、実際の寄付金額はいくらかという詳細な情報とともに、結果が報告されます。
1回の実行、2件の失敗、2つの正確な判断。チームの朝は修正すべき事項がちょうど1件あるところから始まり、コーディングエージェントはすでに必要な詳細情報を手にしています。
まとめ
Auto-Heal Rerunは、有用なテストスイートとノイズの多いスイートを分ける判断を自動化することで機能します。すべての失敗に対して、実際のユーザーのようにフローを再実行し、製品の動作が正常か壊れているかを判断します。ずれであれば適応して検証済みの再実行を行い、本物の問題であれば正確な結果を報告します。
テストを適応させるのであり、アプリケーションコードを書き換えることは決してありません。また、本物のリグレッションに適応することも絶対にありません。AIコーディングセッションが毎週UIを再構成するチームにとって、この判断が自動かつ正確に行われることこそが、グリーンをグリーンたらしめるものです。
TestSprite Standardを使ってAuto-Heal Rerunを有効にし、次のリファクタリングでもテストスイートを生き残らせましょう。