再試行しても不良ロケーターは修正されない 

ログインテストは月曜日に合格し、火曜日に失敗し、水曜日に再び合格しました。ログインフローには誰も手を加えていません。変更されたのは、デザインチームがサインインボタンの周りに追加したコンテナで、これによりボタンが画面の要素ツリー内で1階層下に移動しました。そのボタンを指すXPathは、古いレイアウトに基づいて記述されていました。画面のレンダリング速度によっては、ルックアップが成功する場合と失敗する場合がありました。 

Appiumスイートにおける不安定さは、まさにこのような形で現れることが多い。謎めいた問題ではなく、本来チェック対象ではなかったUIの詳細に依存したテストである。 

皮膚の乾燥には複数の原因がある 

不安定なテストとは、同じコードで合格と失敗を繰り返すテストのことです。規模が大きくなると、コストがかさみます。Atlassian の報告によると、不安定なテストは Jira バックエンド リポジトリの失敗の約 15% を占め、再実行を引き起こし、年間 150,000 万時間以上の開発者時間を無駄にしています。また、Jira Frontend のメイン ブランチ ビルドの失敗の最大 21% の原因となっています (アトラシアン、2025年). 

原因は大きく2つのカテゴリーに分類される。 

• テストが所有する原因。 脆弱なロケーター、実際の待機ではなく固定のスリープ、共有されたテストデータ、順序依存性。これらはコードの中に存在し、修正可能です。 

• 環境要因。 ネットワークから切断されるデバイス、遅いバックエンド呼び出し、予期しないOSダイアログ。これらはコードの外部に存在します。これらを減らすことはできますが、完全に排除することはできません。 

この区別が重要なのは、修正方法が異なるためです。ロケーターが破損した状態でテストを再試行しても、同じエラーがよりゆっくりと発生するだけで、さらに悪いことに、問題が隠蔽されたまま時折テストが成功してしまう可能性があります。まずは、自社で管理しているものから始めましょう。モバイルUIテストでは、通常、ロケーターが最初に確認すべき箇所です。 

アプリが壊れていないのに、なぜ位置情報サービスが壊れるのか 

Appiumのすべてのステップは、要素の検出から始まります。ロケーターとは、テストが要素を見つけるために使用するアドレスのことです。そのアドレスが要素の識別情報ではなく画面の構造を表している場合、レイアウトの変更によってテストが失敗する可能性があります。 

研究者たちはこれをロケーターの脆弱性と呼んでいます。2026年の研究では、359のオープンソースリポジトリを分析し、449のロケーターの破損を再現しました。UIの構造変更によって、アプリケーションは正しく動作しているにもかかわらずテストが失敗したケースです（ReproBreak、ASE 2026その研究はウェブテストフレームワークを対象としていましたが、モバイルでもメカニズムは同じです。要素の名前を変更したり、コンテナを追加したり、リストの順序を変更したりすると、構造ベースのロケーターが別の場所を指すようになります。 

モバイルはさらに2つのプレッシャーを加える。 

• プラットフォームの違い。 同じ画面でもiOSとAndroidでは異なる要素ツリーが生成されるため、1つのXPathが両方で機能することはほとんどありません。 

• レンダリングのタイミング。 モバイル画面は非同期で読み込まれます。要素が存在する前にテストが実行されると、正しいロケーターでも失敗する可能性があります。そのため、ロケーターと待機に関する問題はしばしば同時に発生します。 

AIが生成するテストは、リスクを高める。 

テスト量はチームがレビューできる速度よりも速く増加しています。エンタープライズコードの推定40～50％は現在AIによって生成されています（Digital.ai）、そしてテストコードの生成量も増加傾向にある。 

Slackのエンジニアリングチームは最近、実際のワークフローに対してAI生成のPlaywrightテストを実行しました。生成されたテストは、単純なフローでは約8%、より複雑なフローでは約48%の確率で失敗しました。Slackは、失敗の主な原因はUI状態の変動と、正確な要素ターゲティングを妨げる既存の抽象化にあるとしています（Slackエンジニアリング、2026年これはウェブの話で、モバイルの話ではありませんでしたが、教訓は変わりません。生成されたテストは、与えられたロケーターの習慣をそのまま引き継ぎます。要素の検索方法を誰もレビューしなければ、テストスイートが大きくなればなるほど、検索が不安定になるということです。 

Appium向けの実用的なロケーター注文 

Appiumプロジェクト自身のガイドラインでは、ロケーター戦略をこの順序でランク付けしており、XPathは最後の手段としています。: 

 

1. まずアクセシビリティIDを確認してください。 これはアプリ開発チームが意図的に設定したもので、検索が速く、iOSとAndroidで同じ戦略を採用している。 
2. リソースIDまたはID next。 開発者が名前を変更しない限り、安定しています。 
3. IDが存在しない場合のプラットフォームネイティブクエリ。 iOSでは述語文字列とクラスチェーン、AndroidではUiAutomatorを使用します。XPathよりも精度が高いですが、プラットフォーム固有です。 
4. XPathは最後です。 Appiumのガイドラインでは、この方法は動作が遅く、不安定であるとされています。どうしても使用する必要がある場合は、式を短くし、インデックスベースではなく属性ベースにしてください。 

位置情報の安定性を保つ習慣 

• テスト容易性を「完了」の定義の一部に含める。 アプリ開発チームに、インタラクティブな要素にアクセシビリティ識別子を追加するよう依頼してください。これは、実際のユーザーにとってのアクセシビリティ向上にもつながります。 

• ロケーターを一元化する。 それらをページオブジェクトまたはスクリーンクラスに保持することで、UIの変更が20回の編集ではなく1回の編集で済むようになります。 

• 時間を待つのではなく、状況を待つべきだ。 固定の待機時間を、要素が存在するかクリック可能になるまで明示的に待機する処理に置き換えてください。 

• 生成されたテストを含め、コードレビューでロケーターを確認してください。 インデックスが3つ含まれているXPathは、将来的にエラーの原因となる。 

• 検索失敗は個別に追跡してください。 要素が見つからないエラーが特定の画面に集中している場合、まずはロケーターのクリーンアップが効果を発揮します。 

所有しているものを修理し、所有していないものを管理しましょう。 

安定ロケーターは、完全に制御可能な障害の大部分を排除します。しかし、制御不可能な障害は排除されません。デバイス、ネットワーク、環境は依然として断続的な障害を発生させるため、問題は、テストを手動で再実行することなく、チームがそれらを実際の欠陥とどれだけ迅速に区別できるかということになります。 

それが、信頼性の低さという問題の後半部分であり、次回の記事で取り上げるテーマです。 やり直しは簡単だ。彼らがあなたに言ったことを理解するのは簡単ではない。.