Stanby Tech Blog

求人検索エンジン「スタンバイ」を運営するスタンバイの開発組織やエンジニアリングについて発信するブログです。

トップ > Technology > MagicPod用にAccessibility IDを付与して、NativeAppのテストシナリオ失敗率を抑える

MagicPod用にAccessibility IDを付与して、NativeAppのテストシナリオ失敗率を抑える

Technology

はじめに

こんにちは。株式会社スタンバイ QAグループ（Quality Assurance Group）の樽井です。

スタンバイは求人検索エンジンを開発・運用しており、Webとネイティブアプリ（以降App）でサービスを提供しています。Web・Appのテスト自動化にはMagicPodを利用していますが、本記事では、AppのMagicPodシナリオ1失敗率（シナリオの不備による失敗）を下げるための取り組みをご紹介します。

MagicPod導入の経緯については、過去記事「スタンバイ QAのテスト自動化導入（MagicPod）」をご確認ください。

なぜ失敗率を下げるのか

AppでMagicPod運用を始めた頃のシナリオ失敗率（失敗数※ ÷ シナリオ数）は、Androidが16%前後、iOSが44%前後でした。
※環境やデータなどシナリオ内容以外の失敗数を除いた数

スタンバイでは、テスト自動化の専任者を立てず、Web、AppそれぞれのQA担当者がシナリオ運用を実施しています。
一日1時間前後をMagicPod運用作業に充てていますが、既存シナリオの失敗率が高いことで、修正に時間が取られ、新規シナリオの作成が進まなかったり、新しい機能の反映が遅れたりする影響がありました。加えて、iOSはAndroidに比べて実行速度が遅く、シナリオ修正後の確認にも時間を要します。1つのロケーター2を確定させるのに15分ほどかかることもありました。 加えて、失敗が多いシナリオでは、不具合へ辿り着く前にシナリオが終了してしまい、十分な品質担保ができません。

そこで、シナリオを安定的に実行し、必要な機能実装を進められるよう、失敗率を下げる取り組みを行うことにしました。

MagicPod実行ログから何がわかったか

まずは、シナリオ失敗理由を探るため、Android、iOSそれぞれ過去50回分のMagicPod実行ログを集計し、機能ごとに分類したシナリオの割合を算出しました（シナリオ分類）。さらに、シナリオ分類ごとの平均失敗率を算出し、失敗傾向を大まかに確認しました（シナリオごとの平均失敗率）。

OS シナリオ分類 シナリオごとの平均失敗率
Android
iOS

Androidの特徴

  • 特定の機能が繰り返し失敗している
    • 文字入力できていない
    • 画面遷移後にタップできていない

iOSの特徴

  • 様々な機能で失敗している
    • 画面遷移後にロケーターを取得できていない
    • 画面遷移後にタップできていない
    • 指定した時間内に画面描画できていない

Android・iOS共通に発生していた「画面遷移後にタップできていない」という問題ですが、画面の要素が変動する場合、変動値を含むロケーターを利用していると、データにより要素数が変わることや、スクロール位置によって想定していない要素を操作することがあります。変動値を含むロケーターの方が使いやすいシーンもありますが、固定されたロケーターを利用することで、「XXXが表示されるまでスクロールする」や、「XXXが存在するか確認する」などのコマンドが利用しやすくなります。

データ量やスクロール位置の変動による、ロケーター取得の失敗は、シナリオ作成〜実行〜運用の全てにおいて手間と時間がかかることから、「安定したロケーター取得」を最優先の課題として取り組むことで、失敗率の安定を図りました。

ロケーターを安定させるにはどうすれば良いか〜Accessibility ID〜

そんな折、MagicPodのヘルプセンターで見つけた記事「iOSアプリのテストを高速化するロケーターの選び方」でAccessibility IDの存在を知りました。ロケーターとしての使い勝手の良さとしては、iOS Class ChainやXPathに軍配が上がりますが、今回は流動的な要素ではなく、固定要素に対しての識別を目的としていたため、Accessibility IDの付与を検討しました。

Accessibility IDを付与することで、各UI要素を一意に指定できます。これによりMagicPodから要素を特定しやすくし、ロケーター取得失敗やタップ失敗を防ぐのに役立ちます。iOS、Androidで付与方法が異なり、特にAndroidの場合はUIがViewベースか、Composeベースかにより、IDの割り当て方法が異なります。詳しくは、MagicPodヘルプセンターで見つけた記事「自動テストを簡単にするためのアプリ実装の工夫を知りたい」に記載がありますので、ご覧ください。

事例

記事に記載があるように、Accessibility IDを利用する上での最大のポイントは、開発者にIDを付与してもらう必要があることです。いつ、どのタイミングで、どのように付与するのか、そもそも付与して良いかをApp開発チームのPOに相談することから始めました。開発者に向けては、現在の問題点とAccessibility IDに期待する点についての説明会を実施した上で、ID付与を開始しました。

Accessibility ID付与の流れ

  1. App開発チームのPOに相談
  2. App開発者に説明会
  3. 開発担当者とQA担当者でAccessibility IDの決定
  4. 実装1（開発者）
  5. 付与内容の確認とフィードバック1（QA）
  6. 実装2（開発者）
  7. 付与内容の確認とフィードバック2（QA）
  8. MagicPodシナリオ反映

ロケーターの変化

ID付与前後でロケーターがどのように変化するのか、TextFieldを例にして記載します。もともと、iOS Class Chainで変動的なロケーターを指定していましたが、Accessibility IDを付与したことで、ID指定やIDを起点としたiOS Class Chainを使用できます。これにより、要素を明確に表示させた状態で操作を実施することが容易になります。

Accessibility ID付与前
-ios class chain=**/XCUIElementTypeTextField[1]
Accessibility ID付与後
accessibility id=input_form_abc

または

-ios class chain=**/XCUIElementTypeTextField[`name == "input_form_abc"`]

失敗率はどう変化したか

Accessibility ID付与前後で失敗率を比較したところ、大きな変化が見られました。

Android iOS

iOSの場合、ID付与ありの機能を含むシナリオにて、20%を超えていた失敗率が4%台まで下がり、単純にロケーター取得が失敗することは無くなりました。1ヶ月ほど経過観察しても安定しているため、確実な効果があったと言えます。Androidの場合、iOSよりもID付与ありの機能は限定的ですが、一度失敗率が跳ね上がったものの、現在の失敗率は1%を下回っており、こちらも良い効果があったと言えます。また、Accessiblity IDを起点としたXPathの活用ができるようになり、ロケーターの可読性や安定性が高くなりました。

終わりに

今回はロケーター取得の失敗を減らすことに注力し、Accessibility IDを付与する選択をしました。失敗率を下げることで、シナリオ修正の時間を減らし、結果的にはテスト自動化運用コスト低下につながりました。実行速度を短縮したい、データパターンを活用したい、といったテスト自動化の悩みは尽きませんが、スタンバイの取り組みをどこかでまたご紹介できればと思います。

以上、ここまでお付き合いいただきありがとうございました！

スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com

  1. テストシナリオは、ソフトウェアの特定の機能やフローを検証するために設定された一連の操作や条件のことを指します。シナリオは、テスト自動化ツールによって実行される具体的なステップの集まりです。スタンバイでは、「勤務地を指定して求人を検索する」といった形で、シナリオを分割しています。↩
  2. ロケーターは、テスト自動化において、テスト対象のアプリケーションのユーザーインターフェース（UI）要素を識別し、操作するために使用される方法や手段です。ロケーターは、特定の要素を正確に特定し、テストスクリプトがその要素に対して適切なアクション（クリック、入力、検証など）を実行できるようにします。モバイルアプリの自動化で利用されるものに、Xpathなどがあります。↩