Androidアプリを多言語化するとき、「対応言語の数だけE2Eテストを複製する」という方法は現実的ではありません。実行時間と保守コストが増える一方で、ホーム画面の表示確認に偏りやすく、文字切れ、言語設定の保持失敗、RTLレイアウト、通貨や日付の誤表示といった本質的な不具合を見逃すことがあります。
そこで有効なのが、言語一覧ではなく「リリースマトリクス」からテストを設計する方法です。本稿では、Androidの擬似ロケール、実機上の反復操作、スクリーンショット、OCR、人による言語レビューをどの順番で組み合わせるかを整理します。
言語数ではなく、リスクの組み合わせを定義する
対応言語一覧は製品仕様です。QAで必要なのは、どの条件の組み合わせがリリースを止める不具合を発見できるか、という設計です。
たとえば、次のように各行へ役割を持たせます。
| 役割 | 代表的な条件 | 確認したいリスク |
|---|---|---|
| 基準 | 英語・一般的な端末 | 既存レイアウトからの回帰 |
| 文字列の膨張 | ドイツ語・小画面 | 固定幅ボタン、文字切れ |
| 複雑な文字体系 | タイ語・実機 | フォント、改行、行高 |
| RTL | アラビア語・数字混在 | ミラーリング、句読点、順序 |
| 市場固有 | 日本語・決済画面 | 住所、金額、法的文言 |
すべてのアプリで同じ言語を選ぶ必要はありません。重要なのは、各組み合わせに「なぜテストするのか」を明記することです。理由のない網羅は、結果の意味も曖昧にします。
翻訳完成前に en-XA と ar-XB を使う
Androidの擬似ロケールは、翻訳を待たずにローカライズ可能性を検証できる仕組みです。
-
en-XAは英語文字列を装飾・膨張させ、ハードコードされた文字列や固定幅UIを見つけやすくします。 -
ar-XBは双方向テキストとRTLの構造的な問題を見つけるのに役立ちます。
最初に確認したいのは、主要導線だけではありません。エラー、空状態、権限説明、アップグレード、確認ダイアログも含めます。通常のデモでは表示されにくい状態ほど、未翻訳文字列が残りやすいためです。
ただし、擬似ロケールは実際の翻訳品質を保証しません。ar-XB でレイアウトの反転を確認できても、実際のアラビア語が自然か、句読点が正しいか、文化的に適切かは判断できません。構造確認とネイティブレビューを分ける必要があります。
言語を切り替えた後ではなく、切り替える過程をテストする
対象言語がすでに表示された画面からテストを始めると、重要な状態遷移が抜けます。
Android 13以降では、システム設定からアプリごとの言語を選べます。アプリ内に独自の言語ピッカーがある場合や、旧バージョン向けの互換経路がある場合もあります。それぞれについて、次の小さなシナリオを作ります。
- 新規インストール、アップグレード後、ログイン済みなど開始状態を固定する。
- ユーザーが実際に使う経路から対象言語を選ぶ。
- 画面が即時更新されるか、Activityが再生成されるか、再起動が必要かを確認する。
- 重要画面へ移動し、選択した言語が反映されていることを確認する。
- アプリを終了・再起動し、設定が保持されていることを確認する。
- システム既定へ戻し、以前の翻訳リソースが残っていないか確認する。
この流れにより、単なる表示確認では見つからない「アップグレード時だけ設定が消える」「再起動後に一部だけ旧言語へ戻る」といった不具合を検出できます。
画面は業務リスクで選ぶ
既存の回帰テストを全言語で実行するのではなく、言語によって挙動、レイアウト、信頼性、金銭に影響が出る画面を選びます。
代表例は、オンボーディング、ログイン、検索、詳細、入力フォーム、決済または確認、設定、通知、重要なエラー画面です。固定幅コントロール、動的な値、複数形、サーバーから届く長い文章、下部ナビゲーション、画像上の文字を優先します。
テストデータも重要です。空データだけではなく、現実的な最大長の氏名、住所、商品名、金額を使います。横画面やタブレットは、レイアウトが実際に変わる画面だけ追加すれば十分です。
不具合に合った証跡を選ぶ
一つの技術ですべての多言語不具合を証明することはできません。
- UIツリーや安定したセレクタ：期待する画面・要素が存在するか
- 範囲を限定したOCR：必要なラベルが描画されているか
- テンプレートマッチング：既知のアイコンやダイアログが表示されたか
- スクリーンショット：画面全体の視覚的な文脈
- 構造化アサーション：日付、金額、複数形など決定的なロジック
- ネイティブレビュー：意味、自然さ、トーン、文化的な妥当性
OCRが文字を読めたからといって、文章が自然とは限りません。画像差分があるからといって、必ず不具合とも限りません。セレクタが見つかっても、ボタンの文字が切れて操作不能な可能性があります。証跡が答えられる範囲を明確にします。
実機上で同じ導線を繰り返し、既知状態を待ち、OCRやスクリーンショットを揃える用途では、AI Android自動化ツールを補助レイヤーとして使えます。コードに近いテストや人によるレビューを置き換えるのではなく、反復作業と証跡整理を担当させます。
操作の前後に観測点を置く
安全な自動化では、タップそのものより「タップ前後の状態」を重視します。
操作前に期待する画面を確認し、操作後に遷移先や表示要素を確認します。待機時間には上限を設け、ループ回数も限定します。想定外の同意画面、決済、破壊的操作、未翻訳のシステムダイアログへ到達した場合は、証跡を保存して停止します。
スクリーンショット名には、ビルド、ロケール、端末、画面、状態を含めます。たとえば 145-ja-JP-pixel7-checkout-error.png のようにすれば、後から見ても条件を復元できます。
RTLは独立したテストパスにする
RTLは、LTR確認項目の末尾に一つ追加するだけでは不十分です。アラビア語などの実ロケールで、メールアドレス、電話番号、価格、バージョン文字列、URL、コード、ラテン文字のブランド名を混在させます。
確認対象は、ナビゲーション、ドロワー、タブ、進捗方向、戻るアイコン、数字、単位、カーソル、句読点です。方向を持つアイコンでも、意味に応じて反転すべきものと、反転してはいけないものがあります。
まず ar-XB で構造的な問題を発見し、リリース前には少なくとも一つの実RTL言語でネイティブレビューを行います。
スクリーンショット集ではなく、証跡パケットを作る
条件が不明なスクリーンショットは、別の調査作業を生みます。不具合ごとに次を残します。
- パッケージ名、ビルド、アプリバージョン
- ロケールと地域
- Androidバージョン、端末、解像度、フォント倍率
- テーマと開始時のアカウント状態
- 画面名、期待結果、実際の結果
- 判断を支えるスクリーンショットまたは観測値
ファイルとリリースマトリクスを対応づけるマニフェストも用意します。これにより、許容できる改行差と、価格が隠れる、ボタンが押せない、ブランドロゴが反転する、といった不具合を区別しやすくなります。
まとめ
多言語QAの目的は、最も大きなテストマトリクスを作ることではありません。ユーザーに影響する不具合を発見できる、最小で説明可能なマトリクスを作ることです。
各リリースで、基準言語、文字列が膨張しやすい言語、複雑な文字体系、RTLを代表画面で確認します。翻訳完成前は擬似ロケールを使い、実機の反復操作と証跡整理を自動化し、意味と文化的妥当性はネイティブレビュアーへ任せます。
BeePOS LLCは、LaiCai Screen Mirroringと自動化機能LaiCai Flowを開発しています。本稿には製品提供者としての視点が含まれます。より詳細なチェックリスト、公式資料、実装上の境界については、Androidアプリのローカライズテスト実践ガイドを参照してください。