AI Android自動化でアプリのローカライズテストを効率化

Androidアプリのローカリゼーションテストワークフローを構築します。このワークフローでは、偽のローカライゼーション、実際の言語チェック、RTLレビュー、OCR、スクリーンショット、および人間の判断を組み合わせて、すべてのテストをすべてのローカライゼーションに倍増させることなく実行します。

簡単な答え：ルートを自動化し、言語を確認する

信頼性の高いAndroidアプリローカリゼーションテストワークフローは、繰り返し可能なデバイス作業と言語判断を分離します。言語設定、アプリ起動、ナビゲーション、待ち時間、スクリーンショット、既知の状態チェック、証拠収集を自動化します。翻訳の品質、トーン、文化的意味、曖昧なクリッピング、視覚的なバランスを人間のレビューの下で維持します。目標は、すべての言語ですべてのテストを実行することではありません。ユーザーに最も影響を与える可能性のある失敗を明らかにする、小さく、リスクベースのマトリックスを作成することです。

これは重要な問題です。ローカリゼーションの欠陥は、単に間違った単語だけでなく、ハードコーディングされた文字列、欠落しているリソース、テキスト拡張、右から左へのレイアウトの破損、日付や通貨の誤り、キーボードの不一致、読み取り不能なフォント、クリップされたボタン、永続しない言語設定が含まれます。AIアンドロイド自動化ツール可視ルートを繰り返したり、証拠を集めたりすることはできますが、文が地元の顧客にとって自然に聞こえるかどうかを判断することはできません。

以下のワークフローは、Androidの公式ローカリゼーション機能と観察可能なデバイスチェックを組み合わせています。これは主張するものではありませんLaiCai Flowユニットテスト、コンポーズテスト、Espresso、UI Automator、Appium、翻訳管理システム、またはネイティブ言語レビューを置き換えます。各レイヤーは、それが生成する証拠に最も適しているように使用してください。

言語リストではなく、ローカリゼーションリリースマトリックスから始めます。

サポートされている言語のリストはテストプランではありません。リリースマトリックスは、ローケールを画面、デバイス状態、データ形式、書き込み方向、およびそのローケールを意味のあるものにするビジネスリスクに接続します。その接続がないと、チームは通常、複数の言語でホーム画面を開き、スクリーンショットを取得し、チェックアウト、検索、アカウント回復、通知、または設定の失敗を見逃します。

各リリースごとに、ベースライン言語、拡張に重点を置いた言語、コンパクトまたは複雑なスクリプト言語、および RTL 言語を選択します。市場固有の言語は、ビジネス上のリスクを伴うフローにのみ追加します。Firebase Test LabのAndroidマトリックス同様に、ロケールはデバイスモデル、Androidバージョン、向きのほかに1つの次元として扱われます。つまり、自分のデバイスでチェックを実行する場合でも、便利な計画モデルです。

翻訳が到着する前にAndroidの偽ロケールを使用する

偽ロケールはワークフローの中で最も安価な早期警告システムです。Androidの偽ロケールガイダンス記述する`en-XA`、これは英語のテキストを拡大し、強調します。`ar-XB`、これは右から左への動作を実装します。 それらは、ハードコーディングされた文字列、破損した文字列結合、レイアウト圧力、双方向テキストの問題、および翻訳者が最終コピーを配信する前にミラーリングに失敗する要素を露出させることができます。

• 主なユーザーの旅程を`en-XA`そして、そのままの英語が残っているすべての文字列を記録します。これはハードコーディングされたものか、ローカリゼーションリソースパスの外にあるものかもしれません。
• 同じ旅を繰り返す`ar-XB`ナビゲーションの順序、バックアロー、タブ、進捗インジケータ、混合数、句読点を確認します。
• キャプチャエラー、空、権限、アップグレード、確認ステータスは、通常のハッピーパスのレビューではあまり目立ちません。
• 偽ロケールの失敗を、特定の実際の翻訳が間違っているという証拠ではなく、ロカライズ可能性の欠陥として扱う。

開発者は、選択した画面をさらに早く検査することもできます。Androidのローカリゼーションドキュメントそしてプレビューツールを組み立てるRTLの例を含む、ローカルのプレビューをサポートします。これらのコード隣接チェックは高速で、完全なデバイスワークフローの前にコンポーネントレベルの問題を検出する必要があります。

ユーザーが実際に取る言語パスをテストする

ユーザーが言語を選択、保持、またはリセットできない場合、翻訳された画面だけでは不十分です。Androidのアプリごとの言語ガイダンスAndroid 13以降では、アプリの希望言語の集中管理システム設定が提供されていることを説明し、AndroidXでは古いバージョンでも互換性のあるアプリケーションロケールの処理をサポートしています。アプリには独自の言語選択機能も備える場合があります。サポートされている各エントリーパスには、小さな状態移行テストが必要です。

1. 名前付きのクリーンな状態から開始します。新しいインストール、アップグレードされたインストール、サインインしたアカウント、または復元されたバックアップです。
2. 目的のシステムまたはApp内のパスからロケールを選択し、Appが再起動するか、アクティビティを再作成するか、またはそのまま更新されるかを確認します。
3. 設定から移動し、ターゲット言語環境がビジネスに重要な画面に表示されていることを確認します。
4. App を閉じて再度開き、設定が維持されていることを確認します。
5. システムデフォルトに戻し、古い翻訳されたリソースが残っていないことを確認します。
6. 古いAndroidバージョンでは、Android 13の動作を仮定するのではなく、実際の互換性パスをテストしてください。

デバイスの言語とキーボードの言語は別々の問題です。BrowserStackのローカリゼーションテストドキュメントAndroidデバイスで言語を変更しても、キーボード言語が必ず変更されるわけではないことに注意してください。文字入力エラーがリソースエラーと誤診されないように、マトリックスでその区別を保持してください。

リスク別に代表的なスクリーンを選択する

既存のエンドツーエンドテストをすべてのローケールで掛け算しないでください。ローカライゼーションが動作、レイアウト、信頼性、またはお金を変更するスクリーンを選択します。コンパクトなセットには、通常、オンボーディング、サインイン、ホームナビゲーション、検索、1つの詳細ページ、1つのフォーム、1つの支払いまたは確認サーフェス、設定、通知、および最も重要なエラーステートが含まれます。

固定幅のコントロール、隣接するアイコン、複数の変数、複数ルール、動的サーバーテキスト、コンパクトなカード、下部ナビゲーション、画像よりも翻訳されたテキストを優先します。空のデモデータだけでなく、最大現実的なコンテンツを含む画面を1つ含めます。アプリがタブレット、折りたたみ式、横向きをサポートする場合は、レイアウトが本当に変更される場所にのみそれらを追加します。

選択された各画面に所有者と理由を割り当てます。たとえば、チェックアウト確認画面は、通貨、行のラップ、ボタンラベル、法的コピーを確認するために存在します。アカウント回復画面は、入力方法、エラーメッセージ、双方向のメールアドレスを確認するために存在します。これにより、説明のつかないスクリーンショットのフォルダを作成するのではなく、失敗をアクション可能なものにすることができます。

証拠方法とローカリゼーション欠陥を一致させる

単一のロケータまたは画像技術は、ローカリゼーションの品質を証明するものではありません。 決定をサポートできる最小の観測を選択します。 既存のAndroidの視覚テストガイドUIステート、OCR、画像マッチング、オブジェクト検出、スクリーンショットなどの間のより広範な違いを説明します。ローカリゼーションQAは、これらの方法を実装して言語固有のリスクに対応します。

現在のLaiCai Flow契約では、OCRは魔法のような答えではなく、結果のコレクションを返します。フローは、テキストや位置を比較する前に関連するセグメントを選択する必要があります。同様に、視覚的な一致は既知の状態を報告します。すべてのピクセルや文章が正しいという主張に拡大してはならないはずです。

実際のAndroidデバイスで観察可能なローカリゼーションフローを構築する

チームで、同じナビゲーションを実際のAndroidデバイス間で繰り返し、レビュー者に一貫した証拠を提示する必要がある場合に、可視化されたビジュアルワークフローが役立ちます。LaiCai Flowは、内部にある自動化機能です。LaiCai Screen Mirroring。待ち時間、UI状態チェック、OCR、テンプレートマッチング、スクリーンショット、条件、境界付きループ、明示的な停止などの可視な手順を整理できます。 そのLaiCai Flowガイド製品のワークフローをカバーします。

1. ビルド名、デバイス、Androidバージョン、ローカールール、テーマ、フォントスケール、および開始アカウント状態を指定します。
2. App または設定パスを開き、画面依存の観察の前に明示的な待ち時間を設定します。
3. 一度に1つのユーザーレベルのフェーズをナビゲートし、旅程が複雑になる場合は、技術的な照会詳細を読みやすい子フロー内に保持します。
4. 破壊的または状態変更を行う前に、画面の状態が安定していることを確認してください。
5. 必要なスクリーンショットと、ローケールと画面識別子を含む選択されたOCR結果をキャプチャします。
6. タップが成功したと思い込むのではなく、ナビゲーション後に後続条件を確認します。
7. 画面が不明な場合は、証拠で止めてください。予期しない言語やダイアログを続けてクリックしないでください。

このレイヤーは、コードベースのテストと補完します。コンポーネントと計測器テストは、依然としてリソース照会、状態ロジック、アクセシビリティセマンティクス、およびアプリケーションに近い確率論的な断定を所有する必要があります。サポート、ローカリゼーション、またはリリースレビューアが繰り返し可能なルートと人間が読みやすい証拠パケットを必要とするときに、目に見えるフローが最も強くなります。 そのAndroid QA 煙突テストワークフロー関連する一般的なパターンを提供します。

RTLと双方向コンテンツに独自のテストパスを与える

RTLは、LTRスクリーンショットチェックリストの最後に追加する項目ではありません。アラビア語または他のサポートされているRTLローカルの専用パスを実行し、電子メールアドレス、電話番号、価格、バージョン文字列、URL、コード、およびラテン語のブランド名などの方向別コンテンツを含む混合方向コンテンツを含めます。これらの組み合わせは、完全に翻訳された段落に見られない句読点や順序の失敗を明らかにします。

• ナビゲーション、引き出し、タブ、進捗方向、方向アイコンが意味が反映される場合にのみ反映されることを確認します。
• 数字、単位、製品名、入力カーソルが RTL 文内で読み取り可能な状態であることを確認します。
• 空の状態、ダイアログ、スナックバー、権限説明、フォームバリデーションメッセージの配置を検査します。
• テストスワイプとバックナビゲーションは、すべてのジェスチャーがテキスト方向に合わせて反転するという前提ではなく、行動に基づいて行います。
• 句読点、文法、行送り、文化的解釈については、母国語のレビュアーを使用してください。

使用する`ar-XB`構造的欠陥を早期に露出させ、その後、リリース前に少なくとも1つの実際のRTLローケールを実行します。 偽ローケールはミラーリングの欠陥を明らかにできますが、生産用のアラビア語のコピーのタイポグラフィや意味を検証するものではありません。

テストの形式、入力、通知、および外部表面

最も高価なローカリゼーションの失敗のいくつかは、メインのアプリ画面の外にあります。日付と時刻、小数点区切り符、通貨の配置、アドレスの順序、測定単位、電話番号、複数形、キーボード入力、クリップボードの動作、通知テキスト、ディープリンク、ウェブコンテンツ、および旅程に依存するすべてのシステムダイアログに焦点を当てたチェックを追加します。

各値がどのローケールによって駆動されるかを記録します。アプリ言語、システムローケール、アカウント国、サーバー環境設定、タイムゾーン、キーボードは異なる場合があります。驚くべき値を示すスクリーンショットは有用な証拠ですが、バグレポートにはこれらの入力も明記する必要があります。そうすることで、エンジニアリングチームが不一致のソースを再現できます。

ストアリストとプロモーションのスクリーンショットは、別のリリースサーフェスとして扱います。そのテキストは別のリポジトリから来ており、画像は別のパイプラインによって生成される場合があります。同じスクリーンインベントリと命名スキームを再利用しますが、ストア説明が翻訳されただけでアプリをローカライズしたと見なさないでください。

自動化が弱いところは人間のレビューを維持する

自動化はルートを繰り返したり、既知の証拠を検出したりするのが得意です。人間は、意味、トーン、コンテキスト、文化的適合性、視覚的階層、ユーモア、曖昧さ、および改行が単に異なるように見えるか、実際に理解を害するかについて判断するのが依然として優れています。 手動レビューを予期せぬ例外として扱うのではなく、意図的に引き継ぎを構築します。

• 自動化：ローケール設定、起動、ナビゲーション、待ち時間、安定状態チェック、選択されたテキストの存在、スクリーンショット、ファイル名付け、証拠パッケージング。
• 手動でレビューする：翻訳の意味、自然さ、法的ニュアンス、複雑なスクリプトのアクセシビリティ、曖昧なトリミング、文化的イメージ、および視覚的なバランス。
• コードテストにエスカレーション：正確なリソースマッピング、複数形式のロジック、決定論的なフォーマット機能、およびコンポーネントセマンティクス。
• デバイスまたはフレームワークテストにエスカレーション：システム権限、クロスアプリ動作、キーボード統合、およびライフサイクル移行。

便利な停止ルールはシンプルです。可視状態が承認された状態のいずれでもない場合、証拠を収集して停止します。不明な同意画面、支払い手順、破壊的なアクション、または未翻訳のシステムパスを通じて自動化が継続しないようにしてください。 そのAndroid自動化テストツールの比較各断定を適切なレイヤーに割り当てるのに役立ちます。

リリースチームが対応できる証拠パケットを作成する。

コンテキストのないパス/フラグダッシュボードは、別の調査を作成します。すべてのローカリゼーションの発見は、ビルド、アプリパッケージ、バージョン、ローケールと地域、Androidバージョン、デバイスと解像度、フォントスケール、テーマ、開始状態、画面名、予想される結果、実際の結果、および主張をサポートするスクリーンショットまたは選択された観察を特定する必要があります。

のような安定したファイル名を使用してください。`build-locale-device-screen-state.png`、次に、ファイルをテストマトリックスにマッピングするマニフェストを1つ保持します。 期待される視覚的な変化と欠陥を区別します。 異なる行区切りは許容される場合がありますが、隠された価格、アクセスできないボタン、逆のブランドマーク、または欠落したエラーメッセージは許容されません。 ピクセル差ではなく、ユーザーの影響に基づいて重度さを割り当てます。

現在の世代では、LaiCaiが管理するデバイスが利用できなかったため、この記事では、特定のアプリ、デバイス、またはローケールのベンチマーク結果を主張するのではなく、契約ベースのワークフローを説明します。 マトリックスを拡張する前に、環境で代表的なパイロットを実行してください。

AndroidローカリゼーションQAリリースチェックリスト

1. サポートされているローケールリスト、フォールバックローケール、言語選択パス、およびハイリスク市場を定義します。
2. 走る`en-XA`そして`ar-XB`最終翻訳が到着する前に、代表的な画面で確認します。
3. 各パスがサポートされている、アプリ、システム、およびアプリ内の言語切り替えの実際の検証。
4. 小さな画面で、拡張機能が豊富なロケール、複雑なスクリプトロケール、および RTL ロケールをカバーします。
5. エラー、空、読み込み中、確認、許可、アップグレード、通知のステータスを含める。
6. 地域固有のフォーマット、入力方法、フォントサイズ、ライト/ダークテーマ、言語の維持性を確認します。
7. UIステート、OCR、テンプレートマッチング、スクリーンショット、および人間のレビューは、サポートできる請求のみに使用してください。
8. 名前付きの証拠パケットを保存し、認識されない状態で停止します。
9. ネイティブスピーカーのレビュアーに、意味、トーン、句読点、文化的適合性を承認してもらいます。
10. 主要な自動化CTAは、ローカルのオーナーページに保持し、実装の詳細についてはサポートガイドを使用してください。

著者について：BeePOS LLCは開発していますLaiCai Screen MirroringそしてそのLaiCai Flow自動化機能。このガイドは、現在のAndroidドキュメント、観察されたローカリゼーションテストの実践、および公開されているものを基にしています。LaiCai Flowノード契約。製品に関する質問は、以下を通じて送信できます。LaiCai会社とサポートページ。

ソース

• Android開発者：偽ロケールを使用してアプリをテストします
• Android開発者：アプリごとの言語環境設定
• Android開発者：アプリをローカライズする
• Android開発者：可構成プレビューを使用してUIをプレビューします
• Firebase：Test Labを使用してAndroidのテストを開始する
• BrowserStack：App Liveを使用したローカリゼーションテスト