回答。

モバイルアプリケーションの手動テストは、デバイス（またはエミュレーター）上のユーザーのアクションを通じてモバイルプログラムの動作を確認し、開発要件に適合しているかどうかを検証するプロセスです。

問題の歴史:

スマートフォンの登場により、開発とテストの焦点がデスクトップおよびウェブ製品からモバイルに移りました。モバイルデバイスは特別なアーキテクチャ、限られたリソース、不安定なネットワーク、および特殊なインターフェースの動作を持っており、エミュレーターだけでなく、実際のデバイスでのテスト要件が強化されました。

問題:

モバイルアプリケーションは異なるOSのバージョン、デバイスモデル、さまざまな画面解像度、インターネットの速度で動作します。エラーは通常、あるプラットフォームでは発生し、別のプラットフォームでは発生しません。一部のバグは、マルチタッチ、センサー、再起動、またはアプリケーション間の切り替えに関連しています。

解決策:

テストは次の段階を含みます：

デバイスの準備、エミュレーター/実際のデバイスの設定。
インターフェースのビジネスロジックとネットワークの動作の確認。
Wi-Fiをオフにした時、着信があった時、デバイスがロックされた時の動作のテスト。
インターフェースの適応性と応答性の確認。
アプリのインストール、削除、アップデートの検証。

主な特徴:

異なるOSおよび解像度の実際のデバイスでのテストが必要。
接続状態の変化、呼び出し、通知の際の動作を考慮することが重要。
リソース依存のケース（GPS、カメラ、メモリ、バッテリー）を含むシナリオが必要。

隠れた質問。

エミュレーターのみでテストする際に最も見逃されるバグはどれですか？

バッテリーの問題、動作速度、センサーの問題、プッシュ通知およびハードウェアとの相互作用のエラーは、実際のデバイスでのみ発生します。

古いOSバージョンでアプリをテストすることが重要な理由は何ですか？

APIのサポートとシステム機能の動作（権限、通知）が異なるためです。バグはしばしば古いAndroidまたはiOSバージョンでのみ発生します。

モバイルテストのバリデーションはデスクトップとどう異なりますか？

モバイルテストでは、非標準のシナリオ（電話、SMS、ネットワークの喪失）への反応の確認が必須ですが、これはデスクトップでは必要ありません。

一般的なエラーとアンチパターン

エミュレーターのみでテストする。
不安定なシナリオ（バッテリー切れ、ネットワークの喪失）を無視する。
デバイスとOSのカバレッジが不十分。

実生活の例

ネガティブケース

iPhone 14および最新のAndroidエミュレーター上でのみテストしました。リリース後、Android 7およびXiaomiのユーザーからプッシュ通知が無いことと、通話から戻ったときにフリーズすることについて苦情が寄せられました。

利点:

迅速なテスト、小さいベータ期間。

欠点:

プロダクションに多くの重大なバグがあり、顧客の喪失、ネガティブなレビュー。

ポジティブケース

10台のデバイスプール（異なるブランド、OSバージョン）でテストし、着信、ネットワークの喪失、カメラの切り替えのシナリオを試しました。結果 — バグはリリース前に発見され、要件は遵守されました。