また「element not found」? セレクターとロケーターが壊れたときのテスト方法

「element not found」とは、テストがロケーターで要素を探し、時間内に何も一致しなかったという意味です。解決策がより良いロケーターであることはまれで、本当の解決策はユーザーに見えるものを確認するテストです。

QA エンジニアなら誰でも知っている朝があります: 赤いテストが 20 件、本物のバグは 1 件もない朝です。開発者がクラス名を変え、デザインチームがバナーを動かし、フレームワークの更新が ID を変えました。この記事では、ロケーターが壊れる理由、エラーが出たときの直し方、いつもの対策の限界、そして保守すべきセレクターなしでテストする方法を説明します。

「element not found」とは何か

Selenium 自身のトラブルシューティングのページは、考えられる原因を 3 つ挙げています: 探す場所が違う、探すタイミングが違う、あるいはコードを書いた後でロケーターが変わった、の 3 つです。ロケーターそのものの問題は最後の 1 つだけで、リリースのたびに増えていくのもこの原因です。

セレクターとロケーターはなぜ壊れるのか

ロケーターは、アプリケーションがどう作られているかについての推測です。ユーザーに見えるものを変えずに作りだけを変える変更は、どれもロケーターを壊す可能性があります。

動的 ID と生成されたクラス名

多くのフレームワークは save-8f3a2c や css-1x7hq のような独自の ID やクラス名を書き出します。一意なので完璧なロケーターに見えますが、次のビルドで変わります。それに対して記録したテストは今日は合格し、次のデプロイの後、誰も触っていないページで失敗します。

リデザイン、リファクタリング、A/B テスト

.form > div:nth-child(3) button のような CSS セレクターや //div[3]/form/button[2] のような XPath は、ページの中の道順を表しています。フォームを新しいコンテナーで包む、上にバナーを追加する、2 つのフィールドを並べ替えるだけで、道順は別の場所につながります。A/B テストは同じことを意図的に行い、訪問者の半分はロケーターが想定していないページを受け取ります。

Playwright のドキュメントははっきり書いています: XPath と CSS セレクターは DOM 構造に結びつくことがあり、構造が変わると壊れることがある。

ローカライズとテキストベースのロケーター

テキスト、ラベル、アクセシブルネームによるロケーターはリデザインに耐えるので、推奨されています。しかし翻訳には耐えられません。Save という名前で見つけていたボタンは、フランス語版が Enregistrer と表示すると見つからなくなるため、ローカライズされた製品では言語ごとのロケーターかテスト ID が必要です。

Shadow DOM と iframe

iframe はページの中のページで、Web コンポーネントは内部の要素を shadow root に持っています。Selenium は最上位のドキュメントの要素しか認識しないため、コードで書いたテストにはまずフレームに入るよう指示する必要があり、そうしないと要素は存在しないと報告されます。XPath のように、コンポーネントの中にはまったく入れないロケーターもあります。

仮想化されたリストとグリッド

1 万行の表が速いのは、すべての行を描画しないからです。広く使われているデータグリッドの AG Grid は、画面に見えている部分だけを描画すると説明しており、上下に少しの予備の行を加えるだけです。500 行目は誰かがそこまでスクロールするまでページに存在しないので、ロケーターでは見つからず、人ならただスクロールするだけです。

「element not found」エラーの直し方

Selenium、Playwright、Cypress では、エラーを直すのはあなたの仕事で、リリースのたびに戻ってきます。GUI Test Studio には直すべきロケーターがありません。

GUI Test Studio のテストが要素で止まったときは、次の 5 つの手順で解決でき、コードは一切不要です。

1. 1

   実行の信頼度レポートを開く

   レポートは実行のたびに最初の失敗の箇所で開きます。アサーションがあきらめた瞬間の画面の横に期待画像を表示するので、要素がなかったのか、隠れていたのか、別の場所にあったのかがわかります。

2. 2

   実行の開始地点を確認する

   テストは、その録画を始めた画面から始まります。アプリが別のページにあったり別のデータを持っていたりしたら、元の状態に戻してテストを実行し直してください。

3. 3

   要素が大きく移動したら検索範囲を広げる

   アサーションの検索範囲で何も見つからないと、検索は自動で画面全体に広がります。要素が今後ずっと新しい場所にあるなら、レポートで検索範囲を広げるをクリックし、GUI Test Studio で新しい範囲を設定してください。

4. 4

   意図した変更を採用する

   デザインが変わって要素の見た目が違うなら、信頼度レポートで実際の画像を期待画像として採用をクリックして保存します。編集するコードはなく、テストは最新になります。

5. 5

   要素が本当に消えたならバグを報告する

   要素がなくなっていれば、テストは役目を果たしました。バグレポートをクリックすると、画像を添付した PDF または Jira の課題として登録できます。

CSS、XPath、ロール、テスト ID: どのロケーターにも弱点がある

コードでテストを書くチームは、触れる要素ごとにロケーターを選びます。どの種類も、それぞれのかたちで壊れます。

XPath と CSS セレクターのどちらがよいかは最もよくある質問ですが、見た目ほど重要ではありません。CSS は短くて読みやすく、XPath はページを上にたどったりテキストで探したりできます。どちらもページの作りを表しているので、壊れ方も同じです。

GUI Test Studio では誰もロケーターを選びません。次のセクションで示すとおり、録画したテストが要素ごとに複数の手がかりを自動で保持します。

自己修復型のテスト自動化は壊れたロケーターを直せるのか

自己修復ツールは、テストが合格している間に各要素の追加情報を保存します。メインのロケーターが一致しなくなると、その情報で要素を探して続行します。

どのロケーターも届かない場所: canvas、ゲーム、アクセシビリティツリーのないアプリ

ここまでの戦略はすべて、アプリケーションが自分の要素を説明していることを前提にしています。説明しないアプリケーションも多く、その場合は良いロケーターも悪いロケーターも書きようがありません。

Windows デスクトップアプリについては、アクセシビリティツリーのないアプリのための WinAppDriver の代替で、どのプログラムが自分を説明し、どれが説明しないかを紹介しています。

保守すべきセレクターのないテスト自動化

Windows でエンドツーエンドテストを自動化する GUI Test Studio は、別の道を取ります: 誰もセレクターを書かず、保守もしません。テストは自分で操作の流れを実行して記録するか、プロンプトで説明し、すべてのアサーションはユーザーに見えるものを対象にします。

各要素を見つけるために、GTS Engine + AI は 2 つの道筋を使います。まずアプリケーションに尋ね、Windows アプリがコントロールについて提供するアクセシビリティ情報や、Web ページ自身の要素を使います。アプリケーションが何も言わないときは、画面上で見た目から要素を見つけます。両方の道筋の詳細はGUI Test Studio が画面上の要素を見つける仕組みで説明しています。

Web ページでは: 1 つの要素へ複数の道筋

Web テストでは、GUI Test Studio は操作する各要素への道筋を複数、順位をつけて保存します: テスト ID、ID、ロールと名前、ラベル、プレースホルダー、テキスト、そして最後にページ内の位置です。フレームワークが生成したように見える ID は、人が読めるものすべての後ろ、リストの終わり近くに回されます。

そのため、テスト ID が削除されてもクラス名が変わっても、テストは止まらず、次の道筋が要素を見つけます。同じ道筋で shadow root 内の要素にも届き、スマートフォン向けに生成したテストでは、リンクを隠しているメニューを開くこともできます。

この最後の点こそが、記録した 1 つの Web テストを Chrome、Edge、Firefox、エミュレートしたスマートフォンで実行できる理由で、1 回の記録からのクロスブラウザーテストで紹介しています。

デスクトップアプリでは: まずコントロール、次に画面

Windows アプリでは、ボタンに対して作ったアサーションは、アプリがそのボタンについて伝えた名前、種類、位置を保存します。実行のたびにエンジンはまず動作中のアプリにそのボタンを尋ね、アプリが示す枠の中でその画像を探します。同じボタンが複数ある場合は、記録したボタンがあった場所に最も近いものを選びます。

テキストアサーションは画面上の文字を読む前に要素が何と言っているかをアプリに尋ねるので、画面上で読みにくい言葉でも、アプリが実際に言っている内容と照合されます。

それ以外の場所では: 見た目で

ゲーム、canvas、Citrix セッション、アクセシビリティツリーのないプログラムは、アプリケーションに何も追加せずに見た目でテストします。アサーションは検索範囲の中で要素の画像を探し、テキストアサーションは画面上の文字を読みます。

要素が動いたり変わったりしたときに起きること

1 つのロケーターに依存しないテストでも、変化には対処しなければなりません。各段階で GUI Test Studio が行うことは次のとおりです。

クリックも要素についていきます: 各クリックは直前のアサーションを通して狙いを定めるので、ボタンが動けばクリックも一緒に動きます。各アサーションの設定方法はビジュアルアサーションとテキストアサーションをご覧ください。

それでも人の判断が必要なこと

どんな方法でも、すべての変更がただで済むわけではありません。人が判断するのは次のような場合です。

新しい見た目を採用するではワンクリックの更新を、不安定なテストと誤検知ではアサーションが無害なノイズと本物の変更をどう見分けるかを説明しています。

ロケーターに頼るアサーションが見ないまま通してしまう見た目のバグについては、自動テストが見逃す見た目のバグをお読みください。

要点

• 1「element not found」はたいていバグではなくテストの問題です: 間違っているのはアプリケーションよりも、ロケーター、タイミング、コンテキストであることが多いのです。
• 2ロケーターはありふれた理由で壊れます: 生成された ID、リデザイン、A/B テスト、翻訳、Shadow DOM、iframe、仮想化リストです。
• 3どの戦略もリスクを移すだけです: CSS と XPath は構造に、ロールと名前は言葉に、テスト ID はチームの習慣に、自己修復は人の確認に依存します。
• 4ロケーターに何も出さないアプリもあります: canvas、ゲーム、Citrix セッション、アクセシビリティツリーのないアプリは、見た目でしかテストできません。
• 5GUI Test Studio には保守すべきセレクターもロケーターもありません: まずアプリケーションに尋ね、答えがなければ見た目で要素を見つけ、ユーザーに見えるものを確認します。

よくある質問

Selenium、Playwright、Cypress、AG Grid、Flutter、Qt、Java、Delphi、Citrix、Chrome、Edge、Firefox、Windows は、それぞれの所有者の商標です。