本文へ移動

ホーム / QA / 第2部 テストの基礎

第2部 テストの基礎・第6章

モバイルアプリのテスト

★★☆ 重要6トピック・面接 3問

Web との違いを中心に、モバイルアプリのテストで押さえることをまとめる。

ひとことで

モバイルアプリは、ストアの審査で直すのに時間がかかり、古い版が残り、端末が多く、中断が多いので、Web より事前の確認と互換性が大事。

モバイルアプリのテストは、Web のテストの考え方に加えて、端末・中断・配布・古い版という特有の観点があります。

Web更新:デプロイすればすぐ全員に環境:ブラウザの種類と版中断:タブを閉じる・戻る配布:審査なしモバイルアプリ更新:利用者が更新するまで古い版環境:端末・OS の版・画面の大きさ中断:電話・通知・バックグラウンド配布:ストアの審査がある
Web とモバイルアプリのテストで違うところ
観点テストで気をつけること
リリースのやり直しが難しいストアの審査があり、出したあとも利用者が更新するまで直らない。リリース前の確認を厚くする
古い版が残る新しい API が古い版のアプリを壊さないか(後方互換)
端末の多さ画面の大きさ・OS の版・メーカーの違い。利用の多い端末から選ぶ
中断と状態電話・通知・バックグラウンド・画面の回転のあとに状態が戻るか
通信電波の弱い場所・機内モード・Wi-Fi とモバイル回線の切り替え
権限カメラ・位置・通知の許可を「拒否」したときの動き

面接ではこう答える

モバイルアプリのテストは、Web と比べて4つの違いがあります。1つ目はストアの審査があってすぐ直せないこと、2つ目は利用者が更新するまで古い版が残ること、3つ目は端末と OS の版が多いこと、4つ目は電話や通知、バックグラウンドへの切り替えなどの中断が多いことです。そのため、リリース前の確認を厚くし、古い版との互換性と、中断から戻ったときの状態を必ず確かめます。

ひとことで

利用者の実際の分布から端末を選び、サポートする最も古い OS・画面の大きさの両端・性能の低い端末を加える。

すべての端末で試すことはできないので、利用者の実際の分布から選びます。iOS のシミュレーター(Xcode に付属)や Android のエミュレーターは開発中の確認に便利ですが、最後は実機で確かめます。

シミュレーター・エミュレーターPC の上で動く速く、何台分でも×カメラ・電池・性能は本物と違う手元の実機本物の動き・触り心地通知・カメラ・回線×台数を増やしにくいクラウドの実機サービス多くの機種を借りて使う自動テストを並列に×費用がかかる
テストする端末の3つの選択肢
選び方の観点例
利用の多い端末・OS分析ツールで利用者の多い順に上から選ぶ
サポートする最も古い OS新しい機能(API)が使えない版で落ちないか
画面の大きさの両端小さい画面で文字やボタンが切れないか、タブレットで崩れないか
性能の低い端末起動・スクロールが遅すぎないか
メーカー独自の動き(Android)電池の節約機能で通知や裏の処理が止まらないか

選んだ端末の一覧(サポート端末)はチームで合意して文書にし、OS の新しい版が出るたびに見直します。

面接ではこう答える

テストする端末は、全部は試せないので、分析ツールで利用者の多い端末と OS の版から選びます。それに、サポートする最も古い OS、小さい画面とタブレットのような画面の大きさの両端、性能の低い端末を加えます。シミュレーターやエミュレーターは開発中には便利ですが、カメラや通知、性能は本物と違うので、最後は実機で確かめます。

ひとことで

アプリは中断でバックグラウンドに回り、OS に止められることもある。戻ったときに状態が保たれるかを確かめる。

アプリは、電話や通知、別のアプリへの切り替えでバックグラウンドに回り、メモリが足りないと OS に止められることもあります。戻ってきたときに元の状態に戻れるかは、アプリ特有の大事な観点です。

起動前面で操作中バックグラウンド終了(OS が止める)戻ったとき、入力中の内容・画面の位置・ログイン状態が残っているか電話・通知・ホームに戻る・別のアプリを開く、でバックグラウンドへ
アプリの状態の移り変わりと、テストで見るところ
操作確かめること
入力の途中でホームに戻り、しばらくして戻る入力した内容・画面の位置が残る(または意図どおり消える)
支払いの途中で電話がかかる二重に支払われない、結果が正しく表示される
機内モード・電波の弱い場所分かりやすいエラー、回復したら再開できる
画面の回転・ダークモードの切り替え表示が崩れない、入力が消えない
カメラ・位置・通知の許可を拒否アプリが落ちない。設定への案内がある
通知から直接開く正しい画面に移る。ログインが切れていても迷わない

面接ではこう答える

モバイルアプリは、電話や通知、別のアプリへの切り替えでバックグラウンドに回り、メモリが足りないと OS に止められることもあります。そのため、入力の途中や支払いの途中で中断して戻ったときに、状態が正しく戻るか、二重に処理されないかを確かめます。あわせて、電波の弱い場所や機内モード、カメラや位置の許可を拒否したときにも落ちないかを見ます。

ひとことで

アプリはすぐ直せないので、テスト版の配布で先に確かめ、公開後も一部の利用者から段階的に広げて影響を小さくする。

アプリは出したらすぐには直せないので、テスト版の配布で社内や一部の人に先に使ってもらい、公開後も段階的な公開で影響を小さくします。

ビルドCI で作るテスト版の配布TestFlight などストアの審査数日かかることも段階的な公開一部の利用者から全員へクラッシュ率を見る
アプリのリリースの流れ(一般的な例)
iOSAndroid
テスト版の配布TestFlight(外部のテスターに配るにはベータ版の審査がある)Google Play の内部テスト・クローズドテスト
段階的な公開段階的リリース(自動アップデートを7日間かけて広げる)段階的な公開(割合を指定して広げる)
公開後に見るものクラッシュ率・ストアのレビュー・問い合わせ同左

審査に時間がかかることがあるので、リリースの日程には余裕を持たせます。重大な不具合に備えて、サーバー側の機能フラグで新しい機能だけ止められるようにしておくと、アプリを出し直さずに済みます。

面接ではこう答える

モバイルアプリは、ストアの審査があり、出したあとも利用者が更新するまで直らないので、リリースの前と後に安全策を置きます。前は、iOS の TestFlight や Google Play の内部テストでテスト版を社内や一部の人に配って確かめます。後は、段階的な公開で一部の利用者から広げ、クラッシュ率やレビューを見て、問題があれば止めます。

モバイルアプリの UI の自動テストは、OS ごとの公式の道具と、両方に使える道具があります。Web の E2E と同じく、遅く不安定になりやすいので、主要な流れに絞ります。

道具対象特徴
XCUITestiOSApple の公式。Xcode で Swift で書く
EspressoAndroidGoogle の公式。アプリと同じ仕組みで動き、速く安定しやすい
AppiumiOS・Android1つの書き方で両方に使える。いろいろな言語で書ける
DetoxReact NativeReact Native のアプリ向け

どの道具でも、要素はテスト用の ID(iOS の accessibilityIdentifier、Android の resource-id など)で探すと壊れにくくなります。開発者と相談して、画面を作るときに ID を付けてもらうのが近道です。

ひとことで

アプリは利用者が更新するまで古い版が残るので、API の変更が古い版を壊さないかと、版をまたぐ更新を確かめる。

Web と違い、アプリは利用者が更新するまで古い版が使われ続けます。サーバーの API を変えるときは、今使われているすべての版で動くかを確かめる必要があります。

アプリ v3.0アプリ v3.1アプリ v3.2API を変える日:3つの版が同時に使っている
古い版のアプリは、更新されるまで使われ続ける
確かめること例
API の変更で古い版が壊れない項目の削除・名前の変更・必須の項目の追加をしても、古い版が落ちない
古い版から新しい版への更新保存していたデータや設定・ログイン状態が引き継がれる
強制アップデートサポートを終えた版で起動すると、更新の案内が出てストアに移れる
OS の新しい版ベータ版の OS で、主要な流れが動くか(公開前に確かめる)

どの版をいつまでサポートするか(例:直近の何版まで)をチームで決め、利用者の版の分布を見ながら古い版のテストを減らしていきます。

面接ではこう答える

モバイルアプリは、利用者が更新するまで古い版が使われ続けるので、サーバーの API を変えるときは、今使われている版すべてで動くかを確かめます。特に、項目の削除や名前の変更、必須の項目の追加は古い版を壊しやすいです。あわせて、古い版から新しい版に更新したときにデータやログイン状態が引き継がれるか、サポートを終えた版で強制アップデートの案内が出るかも確かめます。

この章のまとめ

🖨 まとめシート(印刷・PDF)
  • 端末・中断・配布・古い版という、アプリ特有の観点
  • 利用者の分布から端末を選び、最後は実機で確かめる
  • テスト版の配布と段階的な公開で、すぐ直せないリスクを小さくする

この章のクイズ

面接ではこう聞かれる

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1Web アプリとモバイルアプリで、テストの進め方はどう変えますか?

模範回答

考え方は同じですが、モバイルではリリースの後にすぐ直せないので、リリース前の確認を厚くし、公開後も段階的に広げます。

観点としては、端末と OS の版の違い、電話や通知などの中断から戻ったときの状態、電波の弱い場所、権限の拒否、そして古い版のアプリとの互換性を加えます。テスト版を TestFlight や内部テストで配って社内で使ってもらい、公開後はクラッシュ率とストアのレビューを見ます。

深掘りされたら

  • 古い版の互換性は、どこまでテストしますか?

見られているポイントモバイル特有の観点と、リリースの違いの理解

Q2テストする端末は、どうやって選びますか?

模範回答

利用者の実際の分布から選びます。分析ツールで利用の多い端末と OS の版を上から選び、そこに、サポートする最も古い OS、小さい画面とタブレット、性能の低い端末を加えます。

開発中はシミュレーターやエミュレーターで速く確かめ、最後は実機で確かめます。機種を広く見る必要があればクラウドの実機サービスも使います。選んだ一覧はチームで合意し、OS の新しい版が出るたびに見直します。

深掘りされたら

  • シミュレーターでは見つからない不具合の例は?

見られているポイントデータにもとづく選び方と、実機の必要性

Q3「アプリを開き直すと入力した内容が消える」と報告がありました。どう再現・調査しますか?

模範回答

まず「開き直す」が何かを確かめます。ホームに戻って戻ったのか、アプリを終了したのか、時間がたってからか、です。バックグラウンドに回ったあとに OS がアプリを止めると、状態を保存していなければ入力は消えます。

再現には、入力の途中でホームに戻り、別の重いアプリをいくつか開いてから戻る、開発者向けの設定で裏のアプリをすぐ止めるようにする、などを試します。端末と OS の版、空きメモリの状況も記録して報告し、「消えてよいのか、残すべきか」の仕様も PdM に確かめます。

深掘りされたら

  • 仕様として「残すべき」とは、誰がどう決めますか?

見られているポイントアプリのライフサイクルの理解と再現の工夫