皆さん、こんにちは。
先週に引き続き、JSTQBシラバス「モバイルアプリケーションテスト担当者」の2項「モバイルアプリケーションのテストタイプ」をご紹介していきたいと思います。
２項は以下の構成となっています。
■目次リンク 2.モバイルアプリケーションのテストタイプ
・2.1デバイスハードウェアとの互換性テスト
・2.2アプリケーションとデバイスソフトウェアの連携性のテスト
・2.3様々な接続方法のテスト
□2.1デバイスハードウェアとの互換性テスト
こちらでは、モバイルデバイスハードウェアと互換性テストについてとなります。
昨今のモバイルデバイスは、多種多様に存在します。
それぞれすべてを考慮したテストを行おうとすると、途方もない時間と労力が必要です。
また、テスト工数も有限であるため、限られた中で、優先度を決めて、対応していく必要があります。
本項目について、JSTQBシラバスでは、以下の互換性テストについて述べられています。
・デバイス機能
・ディスプレイサイズ
・デバイス温度
・デバイス入力センサー
・デバイス入力（キーボード、ジェスチャー、カメラ）
・画面向き変更
・割り込み
・アクセス許可
・電力／バッテリー
◇2.1.1デバイスの機能テスト
大量のデバイスに対して互換性テストを実施する必要があります。
対象デバイスの優先度付けをテスト用に行う必要があります。
１項でご紹介した「StatCounter」サイトなどを参考に、デバイスの「ポートフォリオ」を選択し、市場カバー率、コスト、リスクを考慮します。
https://susakiworks.com/jstqb_fl_mobaile01/
モバイルアプリケーションは、基本的に、以下特性を備える様々なタイプのデバイスにインストールできると思います。
・様々な方法による電源オフ、ナビゲーション操作
・ハードウェアキーボード、ソフトウェアキーボードの使用
・ハードウェア機能（無線、USB、カメラ、スピーカー、マイクロフォン、ヘッドフォンアクセス）
しかし、OSverが条件に満たしていない、モバイルのみ（タブレットは不可、またはその逆など）の制約がある場合があります。
さらに、最近では指紋センサー搭載のハイモデル、非搭載のローモデルなどのタイプがあり、デバイス機能は、短期間で変更される可能性があります。
◇2.1.2様々なディスプレイのテスト
デバイスのディスプレイには、様々な画面サイズ、ビューポートサイズ、アスペクト比、インチ当たりピクセル数（ppi)で表示される解像度、インチあたりのドット数（dpi)が存在します。
デバイスの多様性を考慮して、優先度づけを行う必要があります。
前回の記事でご紹介した「StatCounter GlobalStats」（https://gs.statcounter.com/）では、「Screen Resolution Stats」で確認することができます。
(例)地域：日本、機種：モバイルに設定した場合
「iOS」の場合
日本は、海外に比べ、Android OSより、iOSの方がシェア率が高くなっています。
iPhoneはプライベートでも使っているけど、解像度に付いてはそこまで気にされる方は多くないでしょう。
例として、「375×667」「414×896」といった解像度は見慣れないことがあると思います。
こちらは、「CSSピクセル」と呼ばれる値となっています。
「CSSピクセル」は、「1 ドットの高さや幅におおよそ一致する、長さの単位」となっており、定義によれば、これは閲覧者の目から腕の長さまで離れた位置での、画素密度 96DPI の単一ピクセルの物理的サイズとのことです。
（参考：https://developer.mozilla.org/ja/docs/Glossary/CSS_pixel）
上記について、一例として、以下サイト「WebデザインABC」様にて、iPhone系の画面解像度のリスト表が掲載されており、確認することができます。
https://webdesign-abc.com/tech/resolution-list/
「375×667」：iPhone6,6s,7,8,SE2,SE3
「414×896」：iPhone XR,XS,11,11Pro
「Android OS」の場合
ではAndroid OSについては、iOSよりも機種も多く、それぞれの独自の解像度となっているため、特定は難しいと思います。
参考として、以下ページにて、各キャリアの解像度リストが掲載されています。
https://screensiz.es/phone
https://qiita.com/nein37/items/3918f5833bfa31fbe3d5
「360×640」：Xperia系、Galaxy系
テストでは、さまざまなデバイスで、対象市場で最も使用されているさまざまな画面サイズ、解像度、アスペクト比を使用してユーザーインターフェースを操作する必要があります。
テストモバイルの画面解像度を選定する場合も、上記「StatCounter GlobalStats」をはじめ、シェア率の高いものをメインに選定し、差分として最大解像度、最小解像度の端末をテスト対象にするなどが良いと思います。
また、JSTQBでは、以下の内容についても、確認する必要があると表記されています。
・アプリケーションは、使用されている画面密度及びサイズに従って、全てのユーザーインターフェース要素を拡大／縮小する。
・ユーザーインターフェース要素の表示は重ならない。
・使用性やタッチ操作の問題は発生しない。
・高dpi/ppiでも、問題となるような縮小は発生しない。
端末機器によっては、文字サイズを変更する、表示サイズを調整するなどが可能なものもあります。
対象となるモバイルアプリケーションの内容に沿ったモバイル端末の選定を行いましょう。
◇2.1.3 デバイス温度のテスト
こちらでは、モバイルデバイスの温度テストについてとなります。
非機能テストに関する内容に該当すると思います。
モバイルデバイスは、バッテリー充電、過度の負荷、バックグラウンドでのアプリケーション実行、モバイルデータ通信やWi -Fi、GPSの連続使用など、さまざまな理由によってオーバーヒート状態になる場合があります。
オーバーヒート状態になると、デバイスは温度上昇を抑え、バッテリーレベルを保持するための動作を行います。
（CPU周波数を下げる、メモリを開放する、システムの一部をオフにするなど）
上記が発生すると、アプリケーションの機能性も影響をうけ、テスト計画する際には考慮する必要があります。
「高負荷のテスト」
デバイスの温度テストを行う場合、高負荷での操作が考えられます。テスト設計する際、長期間にわたり連続して熱を発生させるために、
・通信を短期で連続発生させる
・テスト対象のアプリ起動中に、他アプリの割り込み（電話、アラームなど）を繰り返し行う
などの観点を設けて設計する必要があります。
テスト対象のアプリは、予期しない振る舞いを示さない必要があります。
（アプリの強制終了、フリーズが起きる前に通知を表示させるなど）
◇2.1.4デバイス入力センサーのテスト
モバイルデバイスでは、センサーからさまざまなタイプの入力を受け取るケースがあります。
例として、以下のセンサーがあげられます。
（例）
GPS、加速度計、姿勢制御装置、3軸磁力計を使用するものや、気圧、温度、湿度、心拍数、光、非接触の入力に反応するものなど。
デバイス入力センサーのテストが必要な場合、以下の観点を確認を考慮します。
●アプリケーションの場合
・アプリケーションは、（ウォーキング時のような）回転や前後の動きなど、さまざまなタイプの動きに対しての確認。
●外部の明るさに反応する機能の場合
・様々な明るさ条件下で正しく反応するかの確認。
●サウンドの入力と出力の機能の場合
・ソフト及びハードのボリュームボタン、マイクロフォン、有線及び無線のスピーカー、周囲の様々なサウンド条件と連動して正しく反応するかの確認。
●位置情報
・GPSのオン/オフの切り替えの確認
・様々なGPS信号品質の確認
・アプリケーションがほかの様々な位置決定方法
（Wi-Fi、携帯電話基地局、手動による場所入力）にフォールバック（※１）する必要がある場合。
※１：正常に機能しなくなった際に、性能を制限したり、別の方法に切り替えるなどを行い、限定的な状態でも使用可能な状態を維持すること。
◇2.1.5 様々な入力方法のテスト
デバイスの入力には、様々な方法があります。
・ソフトウェアキーボード／デフォルトキーボード
テキスト入力項目、フォームではデフォルトのキーボード、またはアプリストアからインストールしたソフトウェアキーボードから文字入力が行えます。
テキスト入力可能な項目、フォームを選択した場合、ポップアップでキーボードが表示されます。
テストでは、各キーボード表示後、テキスト入力のバリエーションチェックや、入力文字の制御確認など想定されます。
・ジェスチャーまたはコマンド
こちらは、モバイルやタブレット、マルチタッチが対応している機器で行えます。
「プレス、タッチ、ダブルタッチ、タップ、ダブルタップ」
ボタン選択、チェックボックス選択、ラジオボタン選択、項目選択など該当します。
「マルチタッチ、スワイプ、ピンチオープン/ピンチクローズ」
ペイント操作、ページ切り替え、拡大/縮小などに該当します。
「ドラッグ」
スクロール、バー操作などが該当します。
尚、上記入力操作は、操作可能な個所に対して正しく動作し、対応していない箇所に関しては、ジェスチャー等は受け付けないこともテスト観点として挙げられます。
・アプリケーションで使用されるカメラ
写真をアップロード動画撮影、バーコード読み取り、QRコード、文章スキャン、距離の計測など、カメラを介した入力方法が該当します。
金融系の認証に写真をアップロードしたり、ポイントアプリ、支払いアプリなどで主に利用されると思います。
・全面カメラ、背面カメラの利用
ビデオチャットアプリ、カメラ加工、撮影アプリなどが該当します。
カメラ入力を使用する場合、使用しない方のカメラの動作観点も必要です。
◇2.1.6画面の向き変更テスト
こちらもモバイル端末特有のテスト観点です。
画面の向き変更は、モーションセンサーを使用して検出され、横向きのモード切り替えが発生します。
この際、必要に応じて、ユーザーインターフェースでレイアウトが変更されます。
画面向き変更後のテストでは、以下の項目をチェックします。
・横向き縦向きのモード切り替え時、使用性および機能的な振る舞いは想定通りであること。
・アプリケーションは操作中の状態を維持すること。
・入力データフィールドには、入力済みデータが保持されること。
・出力データフィールドには、使用中のセッションを維持しながら、同じデータが表示されること。
（注意点）
・画面の向きを変更した後のテストでは、単一の切り替えだけに重点を置かないようにする必要があります。
描画や状態の問題は、必ずしも単一の変更後に現れるとは限らないためです。
よって、テストでは、横向き縦向きのモードを切り替えを複数回連続して行う必要があります。
・ユーザーインターフェースの様々な状態で向きを複数回切り替えるテストについて、データの有無を考慮しながら、テスト設計する必要があります。
アプリケーションは期待通りに動作し、データの喪失や変更が発生せずに状態が維持される必要があります。
◇2.1.7典型的な割り込みテスト
デバイスの割り込みの一般的なタイプとして、着信、メッセージ、充電開始、メモリ逼迫、アラーム、その他の通知などがあります。
割り込みテストでは、以下の観点を確認します。
（割り込みテストの観点）
・アプリケーションは、前述の全ての割り込みをアプリケーションの振る舞いに悪影響を及ぼすことなく、正しく処理する。
・発生した割り込みに関係なく、その状態やデータ、セッションを維持しながら機能を正しく処理する。
・通知をブロックする「おやすみ」モードがデバイスに備わっている場合、様々な条件がアプリケーションで正しく使用されることを確認する必要がある。
（長期的に通知ブロックON⇨OFFに切り替え、多数の通知が一度に受信されるケースなど。）
・テストは、アプリケーションの使用中に割り込みを発生させるように設計し、割り込みが悪影響を及ぼさないことを確認する。
◇2.1.8デバイス機能に対するアクセス許可のテスト
こちらは、モバイルアプリケーションがインストールされた後、内部ストレージ（写真、ダウンロード階層など）、外部ストレージ、カメラ、位置情報などアクセス許可を確認することがあります。
また、アクセス拒否した後、再度各項目にアクセスした場合に、アクセス許可を表示するかの確認パターンがあります。
アクセス許可確認のテストでは、以下の観点を確認する必要があります。
・アプリケーションは、アクセス許可の権限が不足している場合でも動作すること。
アクセス許可がない場合は、ユーザーにアクセス許可の付与を求めることができ、原因不明で失敗することがないこと。
・アクセス許可は、上記内部/外部ストレージ、カメラ使用時など、アプリケーションの機能性に関連するリソースに対してのみ要求されること。
関与しないリソースに対する広範なアクセス許可は付与されないこと。
・アクセス許可が削除されるか、インストール時に拒否されても、アプリケーションの機能性は正しく反応すること。
・アプリケーションによって発行されるアクセス要求は、いずれも正確で正当であること。
（アクセス許可を選択しても、実際にはアクセスできない等、発生しないこと）
◇2.1.9 電力消費とバッテリーの状態テスト
こちらも、モバイル特有のテスト観点であると思います。
モバイルアプリケーションでは、特にゲーム系など電力消費が激しいものがあります。
こちらは、主に非機能に関するテスト観点として、考慮するのが良いかと思います。
電力消費とバッテリー状態のテストでは、以下の観点を確認します。
・バッテリーの状態と電力消費に関連する欠陥の確認。
・低電力時及びバッテリー切れ時のデータ整合性確認。
・アプリケーションの通常実行時、低負荷時の消費確認。
・アプリケーションがバックグラウンドで動作している場合の電力消費確認。
□2.2アプリケーションとデバイスソフトウェアの連携のテスト
こちらでは、モバイルアプリケーションと、デバイスソフトウェアの連携についての内容となります。
JSTQBシラバスでは、主な連携としまして、以下が取り上げられています。
・通知
・クイックアクセスリンク
・OS提供ソフトウェア
◇2.2.1通知のテスト
オペレーティングシステムは、様々なメカニズムを使用して通知を表示します。
Android OS、iOS共に端末設定内で通知の制御を行うことができます。
・電力消費を最適化するため、オペレーティングシステムは通知の表示を遅らせる。
・通知を全く表示させない など。
通知テストにおいて、考慮が必要なテスト条件は以下となります。
・低バッテリー条件下で、アプリケーションのフォアグラウンド/バックグラウンド時の通知処理
・通知からアプリケーションのコンテンツに直接アクセスできる場合
・通知からアプリケーションにアクセスでき、アプリケーションの対応するページへのディープリンク（※2）が通知に含まれる場合
※2：デープリンク：アプリの特定の画面に遷移させることのできるリンクのこと。
◇2.2.2クイックアクセスリンクのテスト
「クイックアクセスリンク」は、Windows 10などで、良くアクセスする階層やドキュメントを思い浮かべるとわかりやすいかと思います。
Androidでは、アプリケーションショートカット、iOSでは触覚タッチ(画面長押しで表示されるサブメニュー、プレビュー)及び3D Touchなどクイックアクセスリンクが該当します。
テスト対象ソフトウェアで、上記のようなクイックアクセスリンクが提供されている場合があります。
クイックアクセスリンクについて、考慮が必要なテスト条件は以下となります。
・特定のOSバージョンのみ利用できる場合、インストール先のOSで、その機能の提供の有無に関係なく、テスト対象システムは正しく振る舞う必要がある。
・クイックアクセスリンクで実行されるアクションはアプリケーションが表示された際に、アプリケーションに正しく反映される必要がある。
◇2.2.3オペレーティングシステムで提供されるユーザー設定のテスト
JSTQBシラバスでは、OSによってユーザーに提供されている全ての設定をテストする必要があると表記されています。
私個人の意見としましては、全て範囲が広すぎると思いますので、対象のモバイルアプリケーションに沿った設定項目をテスト範囲とすることでもよいかと考えます。
アプリケーションで特定の設定が考慮されていない場合、ユーザーの操作性に悪影響が及ぶ可能性があります。
例として、デバイスに消音設定がある場合、音声出力してはならないなどです。
OSのユーザー設定テストについて、考慮が必要なテスト条件は以下となります。
・ユーザーは、サウンド、明るさ、ネットワーク、低電力モード、日付と時刻、時間帯、言語、アクセスタイプ、通知など設定オプションの変更が行えること。
・アプリケーションは設定されている基本設計に従って振る舞う。
◇2.2.4 様々なタイプのアプリケーションテスト
モバイルアプリケーションには様々なタイプがあります。
ネイティブアプリ（アプリストアからインストール）、ハイブリッドアプリ（ネイティブとWebアプリの組み合わせ）、Webアプリといったタイプがあります。
それぞれのタイプでは、以下のテスト条件を考慮する必要があります。
◯ネイティブアプリケーションの場合
・デバイス互換
・デバイス機能の使用
◯ハイブリッドアプリケーションの場合
・アプリケーションとデバイスネイティブ機能との連携
・抽象化レイヤの使用に起因する存在的な性能の問題
・対象のプラットフォームのネイティブアプリケーションと比較した使用性
◯Webアプリケーションの場合
・モバイルブラウザに対するアプリケーションのブラウザ間互換性を判断するためのテスト
・様々なJava Scriptエンジンによって機能性に影響を及ぼさないこと
・OS機能の使用
・対象のプラットフォームのネイティブアプリケーションと比較した使用性
◇2.2.5 複数のプラットフォーム及びオペレーティングシステムバージョンとの互換性のテスト
昨今では、モバイルアプリケーションは、クロスプラットフォーム、マルチブラウザでの環境をサポートしています。
各オペレーティングシステムでは、独自の制限があるため、アプリケーションをテストする際には、考慮が必要です。
以下のテスト条件を考慮する必要があります。
・割り込み、通知、最適化（明るさなど省電力）の処理
・マルチプラットフォーム、クロスプラットフォーム開発フレームワークを使用して作成された場合に機能性が損なわないこと。
・プラットフォームが複数のオペレーティングシステムバージョンをサポートする場合、下位互換性のテスト
・プラットフォームに対して新規追加された機能または変更された機能のテスト。
（例）Androidで導入されたDozeフレームワーク（※3）については、サポートするオペレーティングシステムバージョン及びサポートしないオペレーティングシステムバージョンでテストする必要がある。
※3:Android6.0以上で実装され、デバイスが長い間使用されていない場合にアプリのバックグラウンドCPUと、ネットワークアクティビティを保留し、電力消費を抑えるもの。
◇2.2.6デバイス上の他のアプリケーションとの相互運用と共存性のテスト
モバイルでは、他のアプリとの相互連携することが一般的となっています。
SMSアプリ、カメラ、メール、GPSなどです。
考慮が必要なテスト条件は以下となります。
・テスト対象アプリケーションと使用するアプリケーションの間のデータ転送は正しい。
・使用するアプリケーション内に格納されるユーザーデータが破損することはない。
・競合する振る舞い。
（例）電力消費を抑えるためにGPSをOFFにするアプリケーションと、GPSを自動的にオンにするアプリケーションが存在する。
□2.3様々な接続方法のテスト
モバイルデバイスでは、ネットワーク接続が様々あります。
2G（※4)、３G、４G、５Gなどのモバイルデータ通信、WiFi及びNFCやBluetoothなどその他のワイヤレス接続タイプがあります。
※4：2Gのサービスは2012年7月にサービス終了。
〇接続性テストの代替策
接続性のテストとして、モバイルデータ通信⇔WiFi等は一般的と思いますが、それ以外の接続通信を行う場合は、代替策を用意する必要があります。
以下の代替策を考慮する必要があります。
・デバイスエミュレーター/シミュレーター
様々な接続をシミュレーションでき、一部のリモートデバイスアクセスサービスプロバイダーではそのような機能を提供している。
しかし、エミュレーター/シミュレーターの能力は限界がある。
・モバイルネットワークをセットアップし、帯域操作を適用
高価な代替策。
・フィールドテストは存在的に費用対効果の高い代替策。
テストの再現性は限定的。
◯実世界における使用
実世界のモバイルアプリを使用するユーザーは、以下のことが実施可能です。
・WiFi/モバイルデータ通信、バージョン間、GSMセル間（※5)で切り替えることができる。
・移動中にはネットワークを全く利用できないデッドスポットに遭遇することさえある。
・機内モードに切り替えて、ユーザーは意図的に切断することができる。
※5：GSMは2G規格のこと。
ユーザーシナリオなど、ユーザー使用を想定した接続テストで考慮する内容は以下となります。
・様々な接続モードでのアプリケーションに求められる機能性。
・モードを切り換えても、予測しない振る舞いやデータ喪失が発生しないこと。
・ネットワーク接続が制限/利用できない場合、または帯域幅が狭い場合に機能が制限されていることを明確に示す情報がユーザーに提供されること。
■最後に
以上、JSSTQBシラバスモバイルアプリケーションテスト担当者の2項について紹介致しました。
次週は3項について、ご紹介したいと思います。
最後まで読んで頂き、ありがとうございました。
