モバイルアプリのテスト観点｜Web経験者が漏らす12領域

2026 8/26

2026年8月26日 2026年8月26日

「自分の端末では動いたのに、特定機種だけ落ちる」。モバイルアプリのテスト観点は、Webのテストをこなしてきた人ほど、この種の落とし穴を見落としがちです。「バックグラウンドから復帰したら、入力していた状態が消えていた」といった指摘をリリース後に受けて、ヒヤリとした経験はないでしょうか。

Webのテストは手慣れているのに、スマホアプリになると確認すべき範囲が急に広がって見える。その不安の正体は、スマホアプリの確認項目にはWebにない「増える軸」があるからです。

本記事は、Web経験者が漏らしがちなモバイル固有の確認項目を12領域のカタログとして整理し、そのままコピーして使えるチェックリストに落とし込む「実務の地図」です。端末・通信・割り込み・操作・権限まで、抜けの起きやすい領域を、再現手順まで添えて順に見ていきます。

なぜモバイルアプリのテスト観点はWebと違うのか

モバイルアプリのテスト観点がWebと異なる理由は、確認すべき「軸」が増えるからです。ブラウザ上で完結するWebに対し、スマホアプリは端末・OS・通信・OS連携といった外部環境の影響を強く受けます。

Webに上乗せで増える軸

ゼロから作り直すのではなく、増える部分を体系的に足していくのが基本方針です。

Web観点をベースにしつつ、モバイル固有の軸を「上乗せ」するのが正しい考え方です。増える軸は、大きく次の4つに整理できます。

端末の多様性: 機種・画面サイズ・解像度・ハードウェア性能がバラバラ
OSの多様性: iOS／Androidの違い、複数のOSバージョンの併存
状態（ライフサイクル）: バックグラウンド復帰・強制終了・回転など状態が動く
OS連携: 通信・通知・電話・権限・戻る操作など、端末機能との連携で挙動が変わる

Web脳のまま「ブラウザの戻るボタンがある」前提で設計を確認すると、端末側のナビゲーションを丸ごと取りこぼします。この点は後半で独立した領域として扱います。

品質特性の枠組みで捉える

こうした軸は、品質特性の枠組みで捉えると見通しが良くなります。布施昌弘『ソフトウェアテスト教科書』では、機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性という8つの品質特性が示されています。

モバイルでは、このうち多様な環境で動くかを問う「互換性」、片手操作や割り込みに耐える「使用性」、OSやバージョンをまたぐ「移植性」が特に効いてきます。用語の定義や品質特性の体系を確認したいときは、JSTQBの公式サイトも参考になります。

扱う12領域の全体マップ

本記事で扱う12領域を、先に地図として示します。

#	領域	主に効く品質特性
1	端末・OS	互換性・移植性
2	画面（サイズ・セーフエリア）	互換性・使用性
3	通信環境	信頼性
4	割り込み	使用性・信頼性
5	ライフサイクル・状態保持	信頼性
6	権限	使用性・セキュリティ
7	操作・ナビゲーション（戻る・ジェスチャ）	使用性・信頼性
8	端末リソース	性能効率性
9	表示設定	使用性
10	通知	使用性
11	ストア・バージョン互換	移植性
12	非機能（セキュリティ・多言語）	セキュリティ・使用性

次章から、この地図を1領域ずつ具体化していきます。

端末・OS・画面のフラグメンテーションを絞り込むテスト観点

モバイルで最初にぶつかる壁が、端末・OS・画面の組み合わせ爆発です。世に出ている機種とOSバージョンを全網羅するのは現実的に不可能です。だからこそ観点は「網羅」ではなく、何を確認し何を捨てるかの基準づくりに尽きます。

何を捨てるかの基準を先に決める

絞り込みでは、何を確認し、何を捨てるかの基準を先に明文化することが最優先です。優先度は、次の3つの軸で決めます。

市場シェア: 広く使われているOS世代・画面サイズ帯を優先する
自社ユーザー: アプリの利用ログや想定ユーザー層に多い端末を優先する
リスク: 決済・カメラなど、機種差で事故ると被害が大きい機能を優先する

同値クラスの発想とOEM差の限界

この絞り込みは、テスト技法の「同値クラス」の考え方で説明できます。Lee Copeland『はじめて学ぶソフトウェアのテスト技法』では、同じ結果を返すデータの集合を1つのクラスとみなし、各クラスから代表値を1つ選ぶ手順が示されています。端末条件も同じで、似た挙動が期待できる機種を1つのクラスに束ね、代表機種を選べば、確認対象を管理可能な数まで減らせます。

ただし、同値クラスは万能ではありません。Androidの断片化はOSバージョンだけでなく、メーカー独自のカスタムUI（One UIやMIUIなど）やチップセット・GPUの差が主因になります。似て見える端末が同値クラスとは限らないため、絞り込みで漏れたOEM差は、後半で触れる探索的テストで補うのが現実的です。

実機・エミュレータ・クラウド実機の使い分け

実機とエミュレータ／シミュレータは、目的で使い分けます。動作ロジックや画面レイアウトの確認はエミュレータで広くカバーし、実環境依存の部分は実機で確認する、という切り分けが基本です。

「通信は実機でないと再現できない」と断定する必要はありません。通信の劣化は擬似ツールで再現できます。一方で、エミュレータでは再現しにくい典型もあります。

実際のプッシュ配信の到達・遅延
生体認証の実挙動（成功・失敗・センサー個体差）
GPSの実測誤差や測位のふらつき
発熱や実バッテリー消費に伴う挙動
OEMカスタムROM由来のUI・省電力挙動の差

手持ちにない代表機種は、クラウド実機サービス（Firebase Test Lab、AWS Device Farm、BrowserStackなど）で押さえるのが現実解です。画面まわりでは、サイズと解像度に加えてセーフエリアが盲点になりがちで、ノッチやパンチホール、下部のホームバー周辺に重要情報が隠れないかを機種横断で確認します。

絞り込み軸	考え方	確認の狙い
OS別代表機種	iOS／Androidそれぞれで代表的な機種を選ぶ	プラットフォーム差の検出
OSバージョン幅	主要OSの新旧2〜3世代を代表として選ぶ	移植性・後方互換の確認
画面サイズ帯	小・中・大の代表サイズを1つずつ選ぶ	レイアウト崩れの検出
確認対象環境	ロジックはエミュレータ、実依存機能は実機・クラウド実機	コストと精度の両立
優先度	市場・自社ユーザー・リスクで高中低を付ける	限られた工数の配分

自社だけで端末を揃えきれない、あるいは検証工数が足りない場合は、モバイルアプリのテスト外注を検討するという選択肢もあわせて考えると現実的です。

通信環境と割り込みのモバイル固有テスト観点

Web経験者がもっとも取りこぼしやすいのが通信と割り込みです。常時安定した回線を前提にできないこと、そしてOSや他アプリから予告なく処理が中断されることが、その理由です。

通信の観点と再現方法

通信は「つながっている／いない」の二択ではありません。切り替わる瞬間と復帰後の整合こそが核心です。再現方法まで含めて表に整理します。

通信状態	確認する挙動	再現方法
オフライン	エラー表示・キャッシュ表示が適切か	機内モード。Androidは開発者オプションの通信制限や `adb shell svc data disable`
低速回線	読み込み中表示・タイムアウト文言が出るか	iOSはNetwork Link Conditioner、CharlesやProxymanで帯域を絞る
回線切り替え	Wi-Fi↔モバイル回線で処理が壊れないか	実操作で切り替え。プロキシで瞬断を挿入
送信中の切断	二重登録・欠損が起きないか	送信操作の途中で機内モードON、プロキシで通信を落とす

特にデータ送信の途中で回線が切れたとき、二重登録や欠損が起きないかは必ず確認します。

割り込みの観点と起こし方

割り込みは、操作の「途中」で発生させると壊れやすさが表面化します。

割り込みの種類	発生させる状況	起こし方	期待する挙動
電話着信	入力・送信の途中	別端末から発信、シミュレータの着信機能	通話後に元の画面・入力へ復帰
プッシュ通知	動画再生・決済の途中	プッシュ検証ツールやadbで通知を送出	処理が中断・破損しない
アラーム／他アプリ遷移	フォアグラウンド操作中	実操作でアラーム発火・他アプリへ切替	復帰後も状態を保持

途中割り込みの典型と同期競合

こうした割り込み前後の挙動は、状態遷移として観点化すると抜けを防げます。Copeland『はじめて学ぶソフトウェアのテスト技法』第7章の状態遷移テストでは、状態遷移表を使えば状態×イベントの組み合わせを網羅的に洗い出せると説明されています。「操作中」という状態に「着信」「通知」「回線切断」というイベントを掛け合わせ、それぞれの復帰先を表で整理すれば、見落としが可視化されます。

再接続の確認では、同期の競合も見ます。オフライン中に端末側とサーバ側の双方でデータが更新され、復帰時にコンフリクトが起きたとき、last-write-win など期待どおりの解決になるかを確認します。片方の更新が黙って消えないかは、実運用で問い合わせにつながりやすい観点です。

ライフサイクル・状態保持・権限のテスト観点

スマホアプリは、ユーザーが操作していない間もOSによって状態を動かされます。ここを見落とすと、冒頭の「復帰したら状態が消えていた」という不具合が本番で表面化します。

復帰・強制終了の起こし方

ライフサイクルの観点では、次の復帰パターンを確認します。起こし方まで含めて押さえます。

バックグラウンド／フォアグラウンド復帰: ホームに戻して再度開いても状態が保たれるか
OSによる強制終了からの復帰: メモリ不足でプロセスが破棄された後、再生成で状態が復元されるか
再現方法: Androidは開発者オプションの「アクティビティを保持しない」をONにする。他アプリを多数起動してメモリ圧迫でOSキルを誘発する。iOSはメモリ破棄を想定した破棄→再起動で確認する

チェックは「操作手順→期待結果」の粒度で持つと運用しやすくなります。たとえば「入力フォームに途中まで入力→ホームへ戻す→他アプリを操作→アプリに復帰。入力内容が残っていればOK」といった一文で、判定を迷わないケースにします。

画面回転・分割表示

回転やマルチウィンドウでレイアウトが崩れたり、入力が消えたりしないかを確認します。分割表示中のサイズ変更で描画が破綻しないかも対象です。

権限の許可・拒否・後から変更

権限は、許可・拒否だけでなく「後から変更」まで見るのが要点です。

権限（例）	確認する状態	見るべき挙動
位置情報	許可／拒否／後から変更	未許可時のフォールバックが機能するか
カメラ	拒否のまま利用	適切な案内が出て落ちないか
写真／ストレージ	一部のみ許可	権限範囲に応じた表示になるか

権限を「拒否」や「後から変更」した状態でこそ、フォールバック設計の穴が見えます。許可済みの正常系だけを確認して終わると、実利用で頻発するパターンを丸ごと見逃します。

ただし、復帰と権限変更の組み合わせは事前ケースだけで尽くしにくいのが実情です。高橋寿一『知識ゼロから学ぶソフトウェアテスト』第4章では、探索的テストが「明らかにバグを見つける活動」として、テストしながら次の一手を決めていくアプローチだと述べられています。決めうちのケースに加え、端末を触りながら復帰・回転・権限変更を自由に組み合わせる時間を取ると、機種差に起因するバグを拾いやすくなります。

操作・ナビゲーションのテスト観点

戻る操作は、ブラウザの戻るボタン前提のWeb脳のままだと取りこぼす代表領域です。モバイルでは戻る操作がOS側の仕組みに組み込まれており、状態保持や画面遷移を大きく左右します。

Androidの戻る・ジェスチャ・予測型の戻る

Androidには戻るボタン、ジェスチャナビゲーション、さらに予測型の戻る（戻り先をプレビューする挙動）があります。それぞれで、意図した画面へ戻るか、状態が保持されるかを確認します。

iOSのエッジスワイプバック

iOSでは画面端からのスワイプで前画面に戻ります。スワイプの取り消し（途中で指を戻す）や、モーダル表示中のスワイプで想定外の遷移が起きないかを見ます。

戻るでの状態消失・二重遷移・意図せぬ終了

戻る操作では、状態消失・二重遷移（多重pop）・意図せぬアプリ終了の3点が事故りやすい観点です。

入力途中で戻ったときに、内容が消えていないか
連続で速く戻ったときに、画面を飛ばして二重に遷移しないか
ルート画面での戻るで、確認なしにアプリが終了しないか

これらはWebのブラウザ履歴とは挙動が異なるため、Web観点の流用では埋まりません。

端末リソース・表示設定・通知のテスト観点

スマホは、PCに比べてリソースの制約が厳しく、ユーザーごとの表示設定も多彩です。潤沢なリソースと標準設定を前提にすると、実機での劣化を見逃します。

リソースとバックグラウンド実行制限

リソースまわりでは、余裕のない状態での挙動を確認します。

バッテリー・低電力モード: 省電力時に通信や通知が制限され、機能が止まらないか
メモリ不足: 他アプリを多数起動した状態で、落ちたり極端に遅くならないか
ストレージ逼迫: 空き容量が少ないときに保存・キャッシュが破綻しないか

低電力モードとは別軸で、バックグラウンド実行の制限も見ます。Dozeや電池最適化の下で、同期が止まる・プッシュが遅延する・位置取得が停止する、といった挙動を確認します。こうした制約下の応答性や安定性について、高橋寿一『知識ゼロから学ぶソフトウェアテスト』第6章のパフォーマンステストは、機能テストとは別軸で計画的に確認すべき対象だと示しています。

表示設定（ダーク・文字サイズ）

表示設定は、ユーザーが自由に変えられる前提で見ます。

設定項目	バリエーション	確認する崩れ
ダークモード	ライト／ダーク	文字が背景に埋もれないか
文字サイズ	標準／最大	ボタンや文言がはみ出さないか
拡大表示	通常／拡大	レイアウトが破綻しないか

文字サイズ最大とダークモードは、実利用で高頻度なのにテストで抜けやすい二大盲点です。文字サイズや支援機能を掘り下げたい場合は、アクセシビリティテストの進め方を見ると観点をさらに具体化できます。

通知の権限OS差とディープリンク

通知はランタイム権限が絡む点に注意します。iOSは初回にオプトインの許可が必要です。Androidは新しめの世代（Android 13相当以降）で通知の実行時許可が必須で、それ以前の世代では既定で有効という差があります。

未許可の状態で、通知に依存しない代替導線が残っているか
一度許可した後に拒否へ変えた状態で、機能が破綻しないか
通知タップからの起動・ディープリンクで、正しい画面へ遷移するか

ストア審査・バージョン互換・非機能のテスト観点

アプリはリリースして終わりではなく、審査を通し、更新を重ねて使われ続けます。この「入口」と「継続」の観点も、モバイル固有の確認項目です。

ストア審査

権限の利用目的の説明不足や、機能が確認できない状態での提出などが差し戻しの典型です。提出前に、審査観点での自己点検を挟むと手戻りを減らせます。

バージョン互換・データ移行

新規インストールだけでなく、旧バージョンからの更新経路を必ずテスト対象に含めます。見落としやすいのは既存ユーザーのアップデート経路です。

データ移行: 旧バージョンで作ったデータが、更新後も欠損なく開けるか
マイグレーション: ローカルDBのスキーマ変更が既存データを壊さないか
複数バージョン併存: 更新前後のユーザーが混在してもサーバ連携が破綻しないか

非機能：ローカルデータ保護・生体認証・多言語

非機能は入口を押さえ、詳細は専門の観点へ送ります。

領域	入口の観点
セキュリティ	端末内のローカルデータ保護、通信の暗号化
生体認証	成功／失敗／連続失敗ロック／生体未登録時のPINフォールバック／復帰時の再ロック
機微情報	クリップボードへのコピー可否など、機微情報の取り扱い
多言語	文言の切れ・レイアウト崩れ・日付表記

端末に残るデータの保護はセキュリティテストの基本を確認するで、多言語対応の崩れはローカライゼーションテストを見るで、それぞれ深掘りできます。

iOSとAndroidで差が出やすいテスト観点

同じ仕様でも、iOSとAndroidでは挙動が分かれる領域があります。差が出やすい観点を対比で押さえると、片方だけ確認して安心する事故を防げます。

対比表

観点	iOS	Android
戻る操作	画面端のスワイプバック中心	戻るボタン／ジェスチャ／予測型の戻る
権限ダイアログのタイミング	機能利用の直前に提示する設計が主流	実行時に要求、世代で挙動差あり
バックグラウンド制限	OS主導で一律に制限	Dozeや電池最適化、OEM独自の省電力が上乗せ
通知権限のタイミング	初回オプトインの許可が前提	新しめの世代で実行時許可が必須
ストレージ権限の粒度	写真は範囲を絞った選択が可能	世代で粒度が変化、一部のみ許可あり
アプリ間共有	共有シート経由	インテントによる共有

使い分けの指針

OEMの省電力やジェスチャ差が濃いAndroidは実機・クラウド実機を厚く、UIガイドライン準拠を問うiOSは代表機種で押さえる、という配分が実務的です。両OSで同じテストを機械的に流すのではなく、差が出る観点だけOS別にケースを増やすと、工数を無駄なく使えます。

モバイルアプリのテスト観点チェックリストと観点表への落とし込み

ここまでの12領域を、1枚のチェックリストに集約します。この観点カタログを実務で使う際は、下の表を出発点にして自社の観点表へ写し替えるのが近道です。

12領域チェックリスト表

比重は、Webでも見る機能面より、モバイル固有の領域に厚く置きます。

領域	代表的な確認項目	優先度の目安
端末・OS	代表機種・新旧OS世代で起動と主要機能が動くか	高
画面	サイズ帯・セーフエリアでの崩れ・見切れ	高
通信	オフライン・低速・回線切替・送信中断・同期競合	高
割り込み	着信・通知・他アプリ遷移からの復帰	高
ライフサイクル	復帰・強制終了・回転での状態保持	高
権限	拒否・後から変更時のフォールバック	高
操作・ナビゲーション	戻る・ジェスチャでの状態消失・二重遷移・終了	高
リソース	低電力・メモリ／ストレージ逼迫・バックグラウンド制限	中
表示設定	ダークモード・文字サイズ最大での崩れ	中
通知	権限OS差・受信・タップ起動・ディープリンク	中
ストア・互換	審査観点・旧バージョンからの更新・データ移行	中
非機能	ローカルデータ保護・生体認証・多言語表示	中

自社観点表への落とし込み

自社の観点表・優先度への具体的な落とし込み手順は、テスト観点の洗い出し手順を見るで体系的に確認できます。欠陥がどの領域に偏りやすいかといった一般的傾向を押さえるには、IPAのソフトウェア開発分析データのような公的資料も、優先度付けの参考になります。

自動化の線引きと探索的テストの併用

このチェックリストは「抜けを潰す出発点」であって、決めうちのケースだけで安心しないことが大切です。

自動化は領域を選びます。UI自動化（Appium／XCUITest／Espresso）とクラウド並列実行は、回帰や複数端末での起動・主要導線の確認に効きます。一方、割り込み・体感速度・戻る操作の細部・探索は手動が向きます。表で機械的に洗い出したうえで、端末を触りながらの探索的テストを併用すると、事前に想像しづらい組み合わせ由来の不具合を拾えます。

よくある質問（FAQ）

Q. モバイルアプリのテストは、何機種そろえれば十分ですか。

全機種の網羅は不可能なので、機種数を追うより優先度で絞るのが現実的です。市場・自社ユーザー・リスクの3軸で代表機種を選び、似た挙動の端末は1つのクラスに束ねます。ただしOEMのカスタムUI差は同値化しきれないため、代表機種の確認に探索的テストを足して補います。

Q. 実機とエミュレータは、どう使い分ければよいですか。

ロジックや画面レイアウトの広いカバーはエミュレータ、実環境依存の機能は実機、という切り分けが基本です。実プッシュ配信・生体認証・GPS実測・発熱などは擬似環境で再現しきれません。手持ちにない機種はクラウド実機サービスで補うと、コストと精度を両立できます。

Q. Webのテスト観点は、そのまま流用できますか。

機能面の観点は流用できます。そのうえで、端末・通信・割り込み・ライフサイクル・権限・戻る操作といったモバイル固有の領域を上乗せするのが正解です。本記事の12領域を足し算する形で観点表を拡張してください。

Q. 通信断や割り込みは、どう再現すればよいですか。

通信断は機内モードやAndroidの通信制限、低速はNetwork Link ConditionerやCharles／Proxymanで再現します。送信の途中で回線を落とす操作も忘れずに行います。割り込みは別端末からの着信、プッシュ検証ツールやadbによる通知送出、実操作でのアラーム・他アプリ遷移で起こします。