qa-testing-mobile

QA テスト（モバイル）

iOS と Android（ネイティブ＋クロスプラットフォーム）にわたる、信頼性が高くコストを意識したモバイルテストを設計・実行します。

クイックリファレンス

まずワークフローを確認してください。フレームワークと自動化のトレードオフについては専門家の判断を、詳しい情報についてはリソースを参照してください。

クイックスタート

• assets/mobile-test-plan.mdに記入し、リスク、テストレイヤー、ゲートを定義します。
• 分析データをもとにassets/device-matrix.mdに記入し、Tier 1/2/3 のカバレッジを選定します。
• 自動化フレームワークの選定にはreferences/framework-comparison.mdを使用します。
• ベータ版、リリース前、段階的ロールアウト、ロールバックのチェック項目を定義するには、references/release-and-rollout.mdを使用します。
• iOS と Android のアクセシビリティカバレッジを追加するには、references/accessibility-testing.mdを使用します。
• 不安定さの予算、再実行、隔離のルールを設定するには、references/flake-management.mdを使用します。

対象範囲

• iOS と Android にわたるモバイルテスト戦略を定義します。
• デバイスマトリックス、OS カバレッジ、リスク階層を計画します。
• 自動化フレームワーク、CI、デバイスラボの構成を選定します。
• パフォーマンス、ネットワーク／オフライン、バックグラウンド化、権限に対処します。
• リリース前のゲート、段階的ロールアウト、ストア公開準備のチェック項目を定義します。

使用しない場合

• iOS 固有のテストコマンドの詳細 → qa-testing-ios
• Android 固有のテストコマンドの詳細 → qa-testing-android

収集する入力情報

• プラットフォーム、サポート対象の OS バージョン、対象デバイス。
• アプリの種類（ネイティブ、クロスプラットフォーム、ハイブリッド／WebView）。
• 重要なユーザーフローとリスク領域。
• 配布チャネルとリリース頻度。
• ベータ版／リリース用チャネル（TestFlight、Play の内部／クローズドテスト、該当する場合はエンタープライズ配布）。
• 既存のテストツール、CI、デバイスラボへのアクセス（Firebase Test Lab、BrowserStack、AWS Device Farm）。
• 可観測性とロールアウト制御（Crashlytics/Sentry、パフォーマンス／RUM、機能フラグ、段階的ロールアウト）。
• テストデータ戦略（シード／リセット、テストアカウント、環境の同等性）。

ワークフロー

1. 品質リスクと SLI（クラッシュフリー率、ANR、起動時間、重要なフローの成功率）を定義します。
2. 分析データをもとにデバイスマトリックスを作成し、PR ゲートはエミュレーター／シミュレーターを優先します。
3. フレームワークを選定します（デフォルト：XCUITest＋Espresso/Compose。アプリ固有のクロスプラットフォームフレームワークは、総コストを削減できる場合にのみ追加します）。
4. セレクターの保守がボトルネックになっている場合は、自己修復、自然言語による作成、ビジョンベースのテストに対応する AI ネイティブツールを評価します。
5. テストレイヤーを構築します：ユニット、統合／コントラクト、UI スモーク、実機での対象を絞った E2E。
6. モバイル固有のカバレッジを追加します：権限、バックグラウンド／フォアグラウンド、ディープリンク、オフライン／低品質ネットワーク。
7. パフォーマンスチェック（起動、スクロール／カクつき、メモリ）とアクセシビリティ監査を追加します。
8. 不安定さの予算、再実行の上限、隔離ポリシー、失敗のトリアージ（成果物＋再現性）を設定します。
9. リリースゲートとストア公開準備を定義します。ベータチェックを実施し（TestFlight、該当する場合は Play のリリース前レポート）、監視とロールバックを用意して段階的にロールアウトします。

成果物

• モバイルテスト戦略とデバイスマトリックス。
• 自動化計画とフレームワークの選定。
• 優先度を付けたテストケース一覧。
• リリース準備チェックリスト。
• CI パイプラインとレポート計画。

品質チェック

• UI テストは重要なフローに絞り、テストスイートは小さく高速に保ちます。
• デバイス固有のバグとロジックのリグレッションを切り分けます。
• テスト／デバイスごとのフレーク率を追跡し、特に問題の多いものを隔離して修正します。
• 権限、通知、バックグラウンドでの動作を検証します。
• CI は分離されたテスト用バックエンドとシード済みアカウントに対して実行し、本番データがテストによって変更されないようにします。
• アプリがアクセシビリティ、ロケール／タイムゾーン、アップグレード経路に依存する場合は、これらのテスト範囲も含めます。
• ローカライズされたテキストではなく、安定したセレクター（アクセシビリティ ID／テストタグ）を優先します。ビジョンベースのツールでは、画面上に表示される具体的なラベルを使用します。
• AI ネイティブツールを使う場合は、自動生成されたテストをゲートとして信頼する前に、正確性を確認します。ビジョンベースまたは非決定的なチェックは決定的なテストと組み合わせ、PR ゲートとして単独で使わないでください。
• ビジュアルレポートが存在しない一時スクリーンショットのパスを参照している場合は、現在の画面を再キャプチャするか、UI 階層を確認します。一時ファイルの有効期限が切れているという理由だけで、レポートを無視しないでください。
• ベンダーの料金、デバイスの提供状況、ストアポリシーの詳細は、常に変わり得る情報として扱い、確定前に公式ドキュメントで確認します。
• プラットフォーム固有の既知の落とし穴が重要な場合は、一次情報源で現在のバグの挙動を確認し、クロスプラットフォームのスモークテストに頼らず、プラットフォーム固有のテストスイートにリグレッションテストを追加します。
• 新規クローンからの CI ゲート（開発環境側の再生成ツールを使わず、クリーンな git clone からビルド／アーカイブする）を追加します。また、iOS では Build-green だけでなく Archive-green を必須にします。詳細は references/release-and-rollout.md および qa-testing-ios ios-ci-general.md（「Build アクション ≠ Archive アクション」）を参照してください。
• リリースブランチには、現在のストアポリシー（Play の target API、App Store の SDK 最小要件）への準拠と、ロールアウトを停止する基準となる Android vitals の不適切な挙動のしきい値を適用します。references/release-and-rollout.md を参照してください。

配布チャネルの検証

• モバイルリリースの準備状況には、ローカルまたは CI でのコンパイル成功だけでなく、実際の配布経路を含める必要があります。
• iOS では、アーカイブ／署名、TestFlight の準備状況、APNs や StoreKit など本番環境でのみ発生する動作を、本番環境の挙動に一致するチャネルで検証します。
• Android では、ストア側の挙動が重要な場合、Play のトラックまたは同等のストア／デバイスラボの証跡を含めます。
• 各ゲートについて、built、installed、launched、journey-verified、channel-verified、monitored-rollout のいずれかを記録し、ソース／ビルドの識別情報、プラットフォーム、OS／デバイス、ロケール、バックエンド、チャネル、成果物、観測期間も記載します。
• シミュレーター、デバイスラボ、ベータチャネル、本番環境の証跡をひとまとめにして合格扱いにしないでください。後続の段階で前段階の証跡を引き継げるのは、まったく同じビルドと構成の場合に限ります。
• 製品固有のロールアウト順序、メタデータのチェックリスト、レビュアー用アカウント、内部スモークテストスクリプトは、プロジェクトのドキュメントに記載します。移植可能な基本指針については、references/release-and-rollout.md を使用してください。

ローカライズのテスト範囲

ローカライズされた UI またはバックエンドから配信されるローカライズ済みコンテンツを含むアプリには、複数層からなるテスト計画が必要です。

• リソースの欠落を早期に検出する、高速なカタログ／キーの網羅性チェック
• 英語以外のロケールで英語の既定値が気付かれずにリリースされないようにする、値の品質チェック
• 重要度の高い少数のロケールを対象とした、ロケール別レイアウトのスモークテスト
• 該当する場合、バックエンドから配信されるローカライズ済みテキストの統合チェック
• ロケールに依存する要素の指定を避ける、セレクターの適切な使用

ローカライズされた UI の正しさには、レイアウトの一貫性も含まれます。幅が等しい同種のコンテナ、重要な用語が途切れない折り返しラベル、主要コンテンツを隠さないオーバーレイ、最も幅の狭い対応スマートフォンでも使えるコントロールを確保してください。AI ネイティブテストやビジョンテストは、こうした問題の検出に役立ちますが、決定的なカタログの整合性チェックと、対象を絞ったロケール別レイアウトのスモークテストは引き続きゲートとして必要です。

詳しいパターンとトレードオフについては、references/localization-testing.md を使用してください。

専門的な判断

チェックリストだけでは判断できない項目です。特定のチーム、アプリ、ビジネスの状況を読み解く必要があります。

ネイティブかクロスプラットフォームか：メタ判断

フレームワークの判断マトリクス（references/framework-comparison.md）では、アプリの種類に合ったツールがわかります。しかし、そもそもアプリをクロスプラットフォームで開発するべきか、またはすでにクロスプラットフォームであるアプリのテストスイートをクロスプラットフォームのままにするべきかはわかりません。次の点を考慮してください。

• チームの構成は、アプリの構成以上に大きく影響します。 エンジニアリング組織がひとつで、iOS／Android 専任のスペシャリストがいないチームなら、多少の不安定さや保守コストがあっても、Detox／Patrol／Maestro（テストスイートひとつ、スキルセットひとつ）のほうが大きな効果を得られます。一方、iOS と Android の各ポッドが別々にあり、深いネイティブの専門知識を備えているチームなら、XCUITest と Espresso を並行して実行する選択肢もあります。プラットフォームごとにテストを重複させるコストと、共通の抽象化レイヤーを使うコストを比較する前に、代表的なユーザーフローで不安定率、実行時間、保守工数を測定してください。
• 保守コストは積み重なりますが、作成コストは積み重なりません。 クロスプラットフォームのフレームワーク（特に Appium）は、初日には安価に見えます（テストひとつを書けば、ふたつのプラットフォームをカバーできます）。しかし、総保有コストを大きく左右するのは、初期の作成時間ではなく、テストスイートの運用期間を通じた不安定さのトリアージやセレクターの保守です。ネイティブアプリ（RN／Flutter ではないアプリ）に共通のクロスプラットフォーム E2E レイヤーを採用する前に、想定されるテストスイートの運用期間にわたる保守コストと、パイロットでの作成コストを比較してください。
• 通常、アプリ自体のアーキテクチャが結論を決めます。 アプリがすでに React Native または Flutter で構築されているなら、「一貫性のため」に Appium を選んで、そのフレームワーク固有のネイティブテストツール（Detox／Patrol）に逆らう価値はほとんどありません。Appium の不安定さを引き継ぐうえ、フレームワーク固有のツールならそのまま利用できる、より緊密な JS ブリッジやウィジェットツリーとの同期も失われます。
• 固定スケジュールではなく、規模の転換点で再評価してください。 この判断を見直すきっかけとして適切なのは、カレンダー上の日付ではなく、チーム構成の変化（専門家ポッドの結成または解散）やテストスイートの規模の倍増です（保守コストは作成コストとは異なるペースで増加します）。

モバイル E2E を自動化しないほうがよい場合

すべてを自動化してもコストがかからないわけではありません。このスキルでは自動化を基本方針としていますが、次のような場合はその方針を見直してください。

• 画面やフローの変更が、テストの安定化より速い場合。 再設計中の画面、複数のバリエーションが提供されている A/B テスト中のオンボーディングフロー、あるいは 1 四半期以内に廃止される可能性が高い PMF 前の機能は、自動化には適していません。テストが役に立つ前に、保守コストが発生してしまいます。こうしたケースは手動の探索的テストでカバーし、UI が安定してから自動化してください。
• トラフィックが少なく、影響範囲が限定的なフローの場合。 社内向け管理ツール、ほとんど使われない設定画面、影響が限られる低トラフィックのフローには、専用の E2E テストを設ける必要がない場合があります。重大度とデータ損失のリスクも考慮してください。クラッシュレポートだけでは、ユーザーに気づかれない失敗を検出できません。## Inputs to Gather で特定した、重要な経路（認証、購入手続き、主要な価値提案）にあたるフローに E2E 自動化を適用してください。
• チームが不安定なテストの修正を約束できない場合。 誰もトリアージしない UI テストスイートはノイズになり、無視され、やがて回避され、最終的には積極的に信用されなくなります。そうなると、スイートがない場合よりも マイナス の価値（誤った安心感）しかもたらしません。担当者も不安定なテストの SLA もない場合は、E2E カバレッジを増やさず、まず既存のスイートへの信頼を取り戻してください。
• より低コストのテストレイヤーで、すでにリスクをカバーできている場合。 ビジネスロジック、検証ルール、API コントラクトは、UI を操作してテストするよりも、ユニットテストや統合テストのレイヤーでカバーするほうが、ほとんどの場合、より高速で、決定性が高く、保守コストも低くなります。E2E テストは、レンダリング、ジェスチャー、権限、バックグラウンドへの移行、ディープリンク、画面をまたぐナビゲーションなど、デバイス／OS／UI レイヤーを本当に必要とするものに限ってください。
• PMF 前、またはプロトタイプの段階の場合。 プロダクト・マーケット・フィットに達する前で、ユーザーのフィードバックに基づいて UI が毎週変更されることが想定される場合は、小規模な手動スモークテスト用チェックリストと強力なクラッシュレポートのほうが、作成コストを回収する前に書き直すことになる E2E 自動化への投資よりも、通常は効果的です。

不安定なテストのコストとリリース列車の頻度

references/flake-management.md#flake-economics-real-device-vs-simulator では、同じ不安定率でも実機とシミュレーターでコストが異なる理由（再実行の待ち時間、根本原因の内訳、シグナルの価値はいずれも異なります）を説明しています。また、references/release-and-rollout.md#release-train-cadence-and-testing-scope では、テスト範囲をリリース頻度に合わせる方法を説明しています。これには、アプリに実際のユーザーがいる場合にホットフィックスの経路が必須となる理由や、機能フラグを使って「ビルドを安全にリリースしたこと」と「機能を検証したこと」を切り離す方法も含まれます。

テンプレート

• OS とデバイスのカバレッジについては、assets/device-matrix.md を参照してください。
• テスト範囲と自動化については、assets/mobile-test-plan.md を参照してください。
• リリースゲートについては、assets/release-readiness-checklist.md を参照してください。

リソース

• XCUITest、Espresso/Compose、Appium 3（W3C のみ。サポート対象の Node の範囲は npm の engines を確認し、保守中の Node LTS 系統で CI を実行してください）、Detox（New Architecture 対応）、Maestro（docs.maestro.dev）、Drizz、TestSprite、Flutter テスト（Patrol）の選定については、references/framework-comparison.md を参照してください。
• AI ネイティブなモバイルテスト（VLM ベースのテスト、MCP 統合、自己修復、自然言語での作成、意思決定フレームワーク）については、references/ai-native-testing.md を参照してください。
• テストの不安定さを抑えるためのガイダンスについては、references/flake-management.md を参照してください。
• クラウドデバイスファームの選定、調達時の質問、コスト最適化については、references/device-farm-strategies.md を参照してください。
• 起動、ジャンク、メモリ、バッテリーのテストについては、references/mobile-performance-testing.md を参照してください。
• React Native、Flutter、KMP のテストパターンについては、references/cross-platform-test-patterns.md を参照してください。
• TestFlight、Play のリリース前レポート、段階的なロールアウト、ロールバック計画については、references/release-and-rollout.md を参照してください。
• ロケールを段階的に網羅する方法とセレクターの規律については、references/localization-testing.md を参照してください。
• クロスプラットフォームのアクセシビリティに関するリリースゲートの質問と、iOS/Android の監査 API に関する qa-testing-accessibility への参照については、references/accessibility-testing.md を参照してください。
• ゴールデン画像の戦略、ビジュアル差分ツール（Percy、Applitools、Chromatic、Sauce Visual）、qa-testing-android / qa-testing-ios のネイティブスナップショットツールへの参照、ピクセル許容差と知覚的差分、ベースラインの更新頻度、CI アーティファクトのアップロードパターンについては、references/visual-regression-mobile.md を参照してください。
• 単体テスト／統合テスト／E2E テストのコスト特性、ディープリンクやオフラインテストの開始点、テストスイートレベルのアンチパターンについては、references/test-layers-and-suite-anti-patterns.md を参照してください。
• 厳選されたドキュメントとデバイスラボへのリンクについては、data/sources.json を参照してください。

ナビゲーション

計画の出力には テンプレート を、課題に応じた詳細情報には リソース を使用してください。プラットフォームのコマンドの詳細は、関連スキルを参照してください。

関連スキル

スキル	目的
qa-testing-ios	iOS の詳細：XCTest、Swift Testing、simctl
qa-testing-android	Android の詳細：Espresso、Compose Testing、UI Automator
qa-testing-playwright	Web と WebView のテスト
software-mobile	モバイルアーキテクチャのガイダンス

学びのループ

過去の判断や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または利用可能な代替として使う場合に限り、learnings.md を使用してください。どちらも該当しない場合は、両方とも参照しないでください。

適用後、記録する価値のあるパターン、再発防止が必要なミス、または意外だった分野の事実に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使って、日付入りの箇条書きを learnings.md に1件追記してください。SKILL.md 自体は変更しないでください。