デモのエビデンスを見る無料トライアルを開始する
日本語

テストはPlaywright、Selenium、pytestのままご利用いただけます。それらを置き換えることはありません。テストをエンタープライズ対応にし、コード、エビデンス、履歴などすべての所有権はお客様に帰属します。

UIの変更のたびにE2Eテストが壊れるのを防ぐにはどうすればよいですか？

UI変更後にE2Eテストが壊れるのは、クラス、ID、テキストの一部、または位置によって要素を特定しているためであり、これらはデザイン変更によって変わる要素だからです。Verdict System LLCのNexus Studioは、これを3つのステップで処理します。新しいロケーターを提案し、テストを変更する前に確認を求めます。修復されたセレクターによって救われた実行を、クリーンな成功ではなくAUTO_RECOVERとしてマークします。そして、事前に修正できるように脆弱なロケーターを一覧表示します。

執筆：Nexus Studioチーム（Verdict System LLC）。2026年10月7日。

UIが変更されると、なぜPlaywrightやSeleniumのテストが失敗するのですか？

ロケーターは、テストが要素を見つけるために使用するアドレスです。ビルド時に生成されたクラス、ページ内の位置、ラベルの文言など、要素の機能とは無関係なものにアドレスが依存している場合、ページが変更されるとアドレスが不正になり、アプリケーションが正常に動作していてもその行でテストが失敗します。

コストは単一の失敗そのものではありません。リリースのたびに、チームが失敗（レッド）した実行を確認し、該当する行を見つけ、新しいロケーターを探して、ファイルを編集することに費やす時間こそがコストです。

テストをサイレントに修正する自己修復（セルフヒーリング）の何が問題なのですか？

壊れたロケーターを誰にも知らせずに置き換えるツールは、テストスイートをグリーンに保ちますが、変更を隠蔽してしまいます。テストは作成者が選択していないものをクリックするようになり、誰もそれをレビューしていません。新しいマッチが誤った要素であった場合、間違った対象をチェックしているにもかかわらずテストが成功してしまう可能性があります。

Nexus Studioは正反対の原則に基づいて構築されています。ユーザーの知らぬ間に修復されるものは何もありません。

Nexus Studioは壊れたロケーターをどのように修復しますか？

  • 自己修復のデフォルト設定である「Suggest」では、テストが失敗すると、Studioがバックグラウンドでブラウザを開き、失敗した行までテストをリプレイしてページを読み取ります。失敗箇所を開いた時点で、候補がすでに用意されています。これにはAIは使用されておらず、テストはレッドのまま維持されます。
  • 失敗した行のガターから、「Repair line」を使用してそのステップだけを再記録するか、セレクターを候補の1つに置き換えることができます。候補は最も堅牢な順に並んでおり、XPathは最後になります。
  • 変更は未保存の状態でエディタに反映されます。保存することが承認を意味します。
  • どの候補を選択すべきかをAIに尋ねることもできます。AIは候補の並び替えを行うことはできますが、候補を追加することは決してありません。また、ファイルの以前のバージョンはファイルのタイムラインに残ります。

修復されたセレクターでテストがパスした場合、それは何を意味しますか？

判定はAUTO_RECOVERとなります。実行自体は成功しましたが、自己修復機能がそのテスト内のセレクターを置き換える必要がありました。クリーンなパスであるSECUREとして報告されることは決してありません。作成者が記述したロケーターは機能しなくなっており、ページに対する次の変更でテストスイートが実際に壊れてしまうため、誰かが元のセレクターを修正するまで、この保留事項はレポートと履歴に表示されたままになります。

AUTO_RECOVERは7つある合格判定の1つであるため、CIジョブは終了コード0で終了します。この保留事項はレポートに表示され、ビルドの失敗としては扱われません。チェックの完全な順序については、How Nexus Studio decides 14 test verdictsをご覧ください。

壊れる前に脆弱なセレクターを見つけるにはどうすればよいですか？

  • Locator healthは、開いているテストの脆弱なロケーターをそれぞれの行番号とともに一覧表示し、Repair行と同じダイアログを通じて修復します。
  • セレクターマップはAIを使わずにページをスキャンし、各セレクターをHIGH・MEDIUM・LOWで評価して、マップをディスクに保存します。
  • すべてのAI作成テストが合格しなければならない7つのチェックであるVetには、テストに脆弱なロケーターが含まれていないことというルールが含まれています。

Recorderはどのロケーターを選択しますか？

Nexus Recorderは、AIを介さずに、クリックした内容をそのままテストコードとして記述します。テストID属性を使用することも可能です。JavaScriptの記録でdata-testidを選択した場合、data-testidだけでなくdata-qaも読み取ります。PythonおよびSeleniumの記録では、それぞれのランナーの単一の属性名が保持されます。これらの属性に対して記述されたセレクターは堅牢として評価されますが、ビルドによって生成されたクラス名、深いCSSチェーン、タグ名単体などは脆弱として評価されます。

テストは標準的なPlaywrightまたはSeleniumファイルのままですか？

はい。Studioが記述またはインポートするすべてのテストは、チームがすでに知っているフレームワークのコードです。Playwright Testファイル（JavaScript、TypeScript、Python、またはC#）、またはSelenium（JavaScript、Python、Java、またはC#）となります。修復によってそのファイルの1行が編集されるため、Studioの使用を停止した場合でも、移行が必要となる独自フォーマットは存在しません。

限界

  • Suggestモードでの自己修復は、それ自体で何かを修正することはありません。依然として人間が各修復を承認するため、大規模なUI変更にはレビューの時間がかかります。
  • 失敗後の自動読み取りには、マシン上に空きメモリが必要です。メモリが不足している場合は開始されませんが、手動で候補をリクエストすることは可能です。
  • Locator healthはファイルを1行ずつ読み取るため、複数行に分割されたロケーターは検出されません。
  • まだ機能している脆弱なロケーターは失敗ではありません。ロケーターの健全性（Locator health）によって通知されますが、変更を強制されることはありません。

実際に動作している様子はどこで確認できますか？

Studioツアーでは画面上で修復ラインとロケーターの健全性を確認でき、判定ガイドではAUTO_RECOVERを他の13の判定とともに説明しています。また、30日間トライアルではご自身のテストで同じエンジンを実行できます。