【JSTQB FL モバイルアプリケーションテスト担当者】1項モバイル分野

皆さん、こんにちは。
今回は、久しぶりにJSTQB関連の内容をご紹介していきたいと思います。

今回から定期的にJSTQBをはじめとしたソフトウェアテスト、テスト自動化に関する知識・技術系の記事を可能な限り投稿していきたいと思います。

■初めに

JSTQBに関する記事については、過去に「JSTQB Foundation（以下FL）」をご紹介しました。
JSTQBは、ここ近年、シラバスの更新、追加されてきました。
（2022年6月時点）

（JSTQBシラバスリンク）
http://www.jstqb.jp/syllabus.html

本ブログでもFoundation Levelについては取り上げていますが、約1年半前ですので、それから更新されていました。
これらの更新、追加につきましては、ソフトウェアテスト業界の活性化が見受けられます。

ソフトウェア開発が日本でもアジャイル開発が取り入れられ、ソフトウェアの更新頻度が以前よりも短くなり、かつユーザー側も一定の品質・クオリティを求めるようになってきたのではないかと思います。

また、最近では、ソフトウェアの品質を自社で担保するように、社内QA・QC等が増えてきたと思います。
以前までは、スポットで第三者検証会社に一部のテスト、またはテスト工程を依頼し、そこで品質担保となっていたと思います。
現在は、より早くより品質のいいものをいかにエンドユーザーに提供できるかが焦点になってきたとと思います。
そういった場合、スポットでテストを依頼するよりも、自社で品質を担保しつつ、かつ継続的にソフトウェアを提供できるような組織づくりに移行してきたのではないかと思います。
今後は大手企業に限らず、中小企業でも、自社のQC・QAチームを設けて、ソフトウェアのテスト、品質担保を行うようになってきたと思います。

テストに携わる身としては、時代の流れに乗り遅れず、ましては最先端を視野に入れ、常に最新情報をキャッチアップし、自身の糧となるように日々学習を行い、成長していくことが大切ではないかと思います。

前置きが長くなりましたが、本ブログでは、定期的にソフトウェアテスト、テスト自動化に関する情報を発信していこうと思います。
今回は、「Foundation Level Specialist シラバス モバイルアプリケーションテスト担当者」について、数回にわたってご紹介していきたいと思います。

■目次リンク  1.モバイル分野　ービジネスとテクノロジーの原動力

第１章の「モバイル分野」は、以下構成となっています。

・1.1モバイル分析データ
・1.2モバイルアプリケーションのビジネスモデル
・1.3モバイルデバイスの種類
・1.4モバイルアプリケーションのタイプ
・1.5モバイルアプリケーションアーキテクチャ
・1.6モバイルアプリケーションのテスト戦略
・1.7モバイルアプリケーションテストの課題
・1.8モバイルアプリケーションテストのリスク

□1.1モバイル分析データ

「モバイル分析データ」では、モバイルアプリケーションテストで、どのようなプラットフォーム、Osver、デバイス種類、画面サイズ、解像度などが対象であるか分析し、分析データをもとにデバイスを選定する内容が明記されています。

テスト対象となるモバイルアプリケーションが日本国内なのか、国外なのか、OSverはver○以上など、要件定義や設計書、仕様書等から読み解き、選定します。

JSTQBのシラバスでは、上記のようなモバイル分析を行う上で、「StatCounter GlobalStats」が取り上げられています。
こちらは、以下URLでアクセスすることができ、１日のデータ取得数は限られていますが、無償で各カテゴリのシェア率を確認することができます。

「StatCounter GlobalStats」
https://gs.statcounter.com/

上記サイトで確認できる項目としては、以下があります。
・ブラウザ種のシェア
・検索マーケットシェア
・OSシェア
・画像解像度の統計
・ソーシャルメディアの統計
・デバイスベンダーの市場シェア

JSTQBでは、テスト計画の検討とテスト分析を効果的に行うため、モバイルアプリケーションのテスト担当者は次の項目について精通している必要があると明記されています。
・プラットフォーム分布のビジネスへの影響
・プラットフォームごとのアプリケーションダウンロード数
・OSバージョンの量と分布
・さまざまなデバイスの種類の市場分布（地域ごとの特定）
・さまざまな画面サイズと解像度
・さまざまな入力方法
・カメラタイプ

「さまざまな入力方法」「カメラタイプ」以外の項目は、「StatCounter GlobalStats」のページにて、調査することができます。
プロジェクトの初期段階にて、モバイルアプリケーション（Webサイト、Webシステムも含む）の要件、設計書、仕様書等が確認できたなら、モバイルアプリケーションテスト担当者は、モバイル分析を行ってみるとよいでしょう。
OS、画面解像度、デバイスのシェア率が分析で分かったなら、シェア率の高いものをメインのテスト対象として選定することができます。
また、テスト対象の選定理由も、「StatCounter GlobalStats」のデータをまとめて活用することで、強固な裏付けの情報となるでしょう。

◇モバイル分析データの一例

「StatCounter GlobalStats」を利用した一例のドキュメントを以下に掲載しています。

テスト対象調査表_サンプル.pdf
ダウンロードリンク

こちらは、当ブログ「SusakiWorks」を題材にテスト分析、計画、設計、報告書をポートフォリオとしてまとめた際に、作成したシェア率のファイルとなります。
各カテゴリの調査結果をもとに、シェア率の高いものを選定しています。
モバイル分析をはじめ、テスト端末を選定する際の参考資料になると思いますので、ご参考頂ければ幸いです。

□1.2 モバイルアプリケーションのビジネスモデル

こちらでは、モバイルアプリケーションのビジネスモデルのタイプについて、説明されています。

◇「フリーミアムモデル」

（特徴）
・アプリケーションは無償であるが、追加機能は有償
・ユーザーが使いたい機能が十分に備えている、大多数のユーザーが購入したくなる高度な機能を提供する必要がある。

画像編集アプリなどが該当すると思います。
画像を加工した後、その画像を出力するのはオプション料金として課金、購入が必要などです。

◇「広告ベースドアプリケーション」

（特徴）
・ユーザーがアプリケーションを操作すると、画面に広告が表示される。
この収益創出の戦略は、アプリケーションの使用時間が長くなるほど効果的。
・ユーザーインターフェースの設計者は、広告を表示するタイミングに注意する必要がある。

Youtube等の広告で表示されるゲームアプリなど、該当すると思います。
簡単なパズルゲームでも、失敗のルートを見せて、ユーザーに興味を持たせ、広告クリック後、アプリのインストールへ誘導するような手法です。

◇取引ベースドアプリケーション

（特徴）
・取引ごと、定額、または取引価格の一定割合などのいずれかの方法でユーザーに課金する。
このタイプのビジネスモデルはごく少数のアプリケーションのみに適しており、主にモバイルウォレットなどビジネスアプリケーション及び金融アプリケーションで使用される。

仮想通過、株関連のアプリが該当するかと思います。
仮想通過、株関連をモバイルアプリで運用されている方は、認識しやすいかと思います。

◇有償アプリケーション

（特徴）
・ユーザーは料金を支払って、アプリケーションのダウンロード及びインストールを行う。
・無償またはフリーミアムの選択肢が多く存在するため、有償ビジネスモデルを採用する場合は十分に気をつける。

ダウンロード時に料金が発生する有料アプリや、アプリ内で課金を行い、コンテンツを利用するアプリが該当すると思います。
ソーシャルゲームなど該当すると思います。

◇無償アプリケーション及びエンタープライズアプリケーション

（特徴）
・ユーザーに課金されない。
・金融機関やEコマース企業などの組織から多数提供されている。
・組織内での内部使用のために開発され、提供されるサービスへのインターフェースを提供されている。
・組織が提供するサービスにユーザーをアクセスさせることで収益の創出を図る。

銀行のネットバンキングアプリなどが該当すると思います。
アプリ上で、振り込み・振替、外貨預金、定期預金などを組む際などです。

□1.3モバイルデバイスの種類

こちらでは、モバイルデバイスの種類について記載されています。
JSTQBシラバス内で取り上げられている種類は、以下となります。

◇ベーシックフォン

通話機能を主として必要最低限の機能だけ搭載した端末のこと。

（特徴）
・電話とSNSだけに使用
・内臓アプリケーションやゲームはほとんどない
・アプリケーションのインストールやインターネット参照は不可能

◇フィーチャフォン

携帯電話の中で、通話機能をメインとして持ちながら、カメラやワンセグなど高機能を搭載している端末のこと。

（特徴）
・アプリケーションとアプリケーションのインストールに対する限定されたサポートを提供する。
・内臓のブラウザを介してインターネットアクセスが可能であり、カメラが追加ハードウェアを搭載している場合もある。

◇スマートフォン

AndroidやiPhoneなどといった現在の主流となるモバイル端末のこと。

（特徴）
・複数のセンサーを搭載した電話
・オペレーティングシステムにより、アプリケーションのインストール、マルチメディア及びインターネットの閲覧などの機能がサポイートされる。

◇タブレット

板状のオールインワン・コンピュータ周辺機のこと。

（特徴）
・物理的なサイズがスマートフォンに比べて大きい。
・より大きな画面が必要とされる場合に使用されることが多い。

◇コンパニオンデバイスと一部のIoT製品

主となる端末との併用を前提する端末で、Airpod、AirTagなどIoT機器のこと。

・コンピューター駆動のデバイスで、スマートフォンやタブレットと連携して使用され、利用可能な機能を拡張する、またはスマートフォンやタブレット上のデータへのより使いやすい方法でアクセスを可能にする機器。

◇ウェアラブル

着用、身に着ける機器のこと。

・利用者が身に着けることができるデバイス
スマートウォッチ、スマートブレスレット

□1.4モバイルアプリケーションタイプ

モバイルアプリケーションのタイプとして、以下3つの種類が取り上げられています。
・ネイティブ
・ブラウザベース
・ハイブリッド

◇ネイティブアプリケーション

ネイティブアプリケーションの特徴としては、以下となります。

・プラットフォーム固有のソフトウェア開発キット(SDK)、開発ツール、プラットフォーム固有のセンサーや機能を使用して開発。
・サプライヤ（例：Apple Store,Google Playなど）のストアからダウンロード、インストール、およびアップデートを行うことがある。
・サポート対象の全デバイスでのテストが必要。
・一般的に優れた性能を発揮し、プラットフォームの機能をフルに活用、開発対象となるプラットフォームに求められるものに適合する。
・開発コストは高くなる傾向にあり、複数プラットフォームの使用や大量のデバイスでのインストールやテストなどの課題が追加で発生する可能性。

◇ブラウザベースドアプリケーション

ブラウザベースドアプリケーションの特徴としては、以下となります。

・モバイルブラウザを介してアクセスされる。
・典型的なWeb開発技術とブラウザが使用されるため、複数プラットフォームのサポートを容易に実現でき、開発コストも一般的に低い。

尚、モバイルアプリケーションの開発方法について、以下4項が紹介されています。

「モバイル固有バージョンのWebサイトおよびアプリケーション（ｍ（dot）サイト）」
・モバイルブラウザからアプリケーションにアクセスすると、モバイルバージョンのアプリケーションが提供される。
例：モバイルデバイスからfacebook.comにアクセスすると、m.facebook.comに転送される

「レスポンシブWebアプリケーション」
・ビューポートとして一般的に表現されるフォームファクターと画面サイズに合わせてデザインが調整される。
（PCのブラウザで該当のページにアクセスし、ウィンドウサイズを調整しても最適に表示されるもの）

「アダプティブWebアプリケーション」
・事前の定義サイズに従ってデザインを調整、サイズ向けに異なるデザインが存在し、ユーザーが利用できる機能は調整できる。

「プログレッシブWebアプリケーション」
・Webページのショートカットをモバイルホーム画面上に作成、ネイティブアプリケーションのように表示され、オフラインで動作するものもある。
例：Safariブラウザで、Webページを開き、中央のアイコン選択⇒ホーム画面に追加など

◇ハイブリッドアプリケーション

ハイブリッドアプリケーションは、ネイティブアプリケーションとWebアプリケーションを組みわせて使用します。

・Webアプリケーション
Webビューを含むネイティブアプリケーションラッパー（Webviewアプリ）を使用して、ネイティブアプリケーション内で実行する。
開発、アップデート、メンテナンスは比較的容易であり、デバイスにインストールされているアプリケーションをアップデートする必要はない。
開発に必要なスキルはは、Web開発の場合とほとんど同じ。
インターネット接続が必要である。

（Webアプリケーションの弱点）
・ラッパー使用による性能の問題がある。
・プラットフォームによっては期待されるルックアンドフィール（グラフィカルなユーザーインターフェースデザインと、ボタンやテキストボックスといった動的要素のふるまい）からの逸脱など発生する可能性がある。

「ネイティブアプリケーションとハイブリッドアプリケーション」
プリインストールのアプリケーションの他、配布チャンネルを介してインストールできる。
配布チャンネルには、Apple Store、Google PlayStore、エンタープライズアプリケーションストア、サードパーティアプリケーションマーケットなどある。

インターネットに接続されているか関係なく、利用が可能。
（最近の傾向では、データ読み込み等、通信の発生を必要とするものが多く、インターネット接続は必須と私は思います。）

※考慮すべき事項
ネイティブ、ブラウザベース、ハイブリッドのそれぞれで、考慮すべき事項について、以下が挙げられています。

・異なるタイプのデバイスをサポート
・センサー及びデバイス機能を使用
・さまざまなネットワーク条件での可用性
・設置性、互換性、性能効率性、使用性

□1.5モバイルアプリケーションアーキテクチャ

こちらでは、モバイルアプリケーションアーキテクチャ（構造／構成）について記載されています。
機能仕様の他、非機能に関する仕様項目が該当すると思います。

◇特定のアーキテクチャの選択または設計の意思決定を行う際に考慮事項

・対象にするユーザー
・アプリケーションタイプ
・さまざまなモバイルプラットフォーム及び非モバイルプラットフォームのサポート
・接続性のニーズ
・データストレージのニーズ
・IoTアプライアンスを含むほかのデバイスへの接続

◇アーキテクチャに関しての意思決定を行う項目

・シンクライアント、ファットクライアント、クライアント側のアーキテクチャ
・シングルティア、マルチティアなどサーバー側アーキテクチャ
・Wi-Fi、モバイルデータ通信、近距離無線通信（NFC)、Buletooth
・ストアアンドフォワード、プッシュ/プル、同期/非同期通信などのデータ同期方法
以上が掲載されていますが、上段2項は、あまり聞きなれません。
以下に概要レベルではありますがまとめています。
単語だけでも、覚えておくのがいいかもしれません。

◯シンクライアントアプリケーション

シンクライアント（ユーザーが使うクライアント端末に必要最小限の処理をさせて、ほとんどの処理をサーバー側に集中させるもの）のアプリケーションを指します。

（特徴）
・デバイス固有のアプリケーションコードを含まず、モバイルオペレーティングシステム機能の使用は最小限。
・これらのアプリケーションでは、フロントエンドとしてのWebブラウザを、クライアント側のロジックに実装するための言語としてJavaScriptを使用する。

◯ファットクライアント（シッククライアント）アプリケーション

ファットクライアント（パソコンのようにクライアント側であらゆる処理が実行できるように記憶媒体や、ソフトウェアなどの環境をすべて実装したもの）のアプリケーションを指します。

（特徴）
・複数のレイヤーのアプリケーションコードを持つことが可能であり、モバイルオペレーティングシステム機能を使用できる。
・これはネイティブアプリケーションまたはハイブリッドアプリケーションであることが多い。

◯シングルティアアーキテクチャ（サーバー側）

一体型であり、全てのサーバーが同一マシン上に存在します。
拡張性に乏しく、安全に保護することが困難です。

◯マルチティアーキテクチャ（サーバー側）

さまざまなユニット全体でサーバー側コンポーネントを分散配布します。
多層分散システムシステムとも呼ばれます。

・２ティアアーキテクチャ
Webサーバーとデータベースサーバーを分離する。

・3ティアアーキテクチャ
Webサーバーとデータベースサーバーを分離の他、アプリケーションサーバーも分離する。
メリット：処理の分担が可能であり、データベース専門化を実現し、柔軟性、拡張性、セキュリティに優れている。
デメリット：開発、管理、ホスティングの費用がシングルアーキテクチャに比べて極めて大きい。

◇モバイルアプリケーションの動作モード

以下にモバイルアプリケーションで動作する3つのモードが記載されています。

・接続されることのないアプリケーション
オフラインで動作し、接続を必要としない。
例：電卓など

・常時接続アプリケーション
動作時に常時ネットワーク接続を必要とする。
全てのモバイルWebアプリケーションはこのカテゴリに分類。
一部のアプリケーションは必要時接続のモードでも限定的に動作できる。

・必要時接続アプリケーション
長時間にわたって接続なしで動作でき、データ転送などのタスクにおいて接続を必要とする。

◇クライアントとサーバーの間のデータ同期

クライアントとサーバー間のデータ同期は、以下2つが挙げられています。
・連続モード：データはサブミットされるとすぐに転送される
・ストアアンドフォワードモード：特に接続が利用できない場合に、データはローカルに保存され、その後転送される。

◇データ転送

データ転送については、以下2つが挙げられています。

・同期データ転送
呼び出した側の関数は、呼び出された側の関数が完了して実行権を返すまで待機する。

・非同期データ転送
呼び出された側のサーバー関数は、実行権を直ちに返し、データをバックグラウンドで処理後、タスクの完了ごに呼び出した側のクライアント関数にそのことを通知する。

□1.6モバイルアプリケーションのテスト戦略

モバイルテスト戦略を作成する場合、モバイル固有のリスクや課題を追加で考慮する必要があります。

◇リスク

・モバイルデバイスの多様性と、一部のデバイスでの固有の欠陥
・社内または外部テストラボの使用によるデバイスの可用性
・アプリケーションライフサイクルにおける新しい技術、デバイス、またはプラットフォームの導入
・多様なチャンネルを介してのアプリケーション自体のインストールとアップグレード
・アプリケーションに影響を及ぼす可能性のあるプラットフォームの問題。
・世界中で使用されることを考えた場合のネットワークのカバレッジとアプリケーションに及ぼす影響
・多様なサービスプロバイダのネットワークを使用してのテストの可能性
・特定のテストレベル及びテストタイプ向けのモバイルエミュレータ、シミュレーター、実デバイスの使用

JSTQBのシラバスでは、上記リスクや、課題について取り上げられています。
個人的には、直近ではありますが、コロナ禍により、リモートワークのため、モバイル実機の手配、テスト実施に課題があるのでは思います。
第三者検証会社であれば、モバイル検証機は豊富にそろえられていると思いますが、中小企業の場合、モバイル実機の種類はそれほど多くないため、テスト実機の手配は課題として上がると思います。
プライベートでAndroid、iPhoneはどちらか片方を持っているが、もう片方は持っていないなどです。
また、最新機種でのテスト、画面サイズ別でのチェックなども課題として挙げられると思います。

◇テスト戦略で考慮するリスクと課題

テスト戦略では、リスクと課題について考慮する必要があります。
以下その例となります。

・開発の初期段階でモバイルデバイスエミュレーター・シュミレーターの使用を、皇族の段階では実デバイスの使用を、テスト戦略で指定される可能性がある。
特定のテストタイプでは、モバイルエミュレータ/シミュレータでテスト実行できるが、できないテストタイプも存在する。

・大量の異なる種類のデバイスの準備と課題に対して、以下アプローチを考慮することが必要な場合がある。

（テスト戦略での課題に対するアプローチ）
・シングルプラットフォームアプローチ
1つのデバイスタイプ、1つのOSバージョン、1つの通信事業者、1つのネットワークタイプにテストスコープを削除する。

・マルチプラットフォームアプローチ
モバイルトラフィックまたは他の分析データに基づいて、ターゲット市場の大半の顧客により使用される代表的なデバイスとOSにテストスコープを削減する。

・最大カバレッジアプローチ
すべてのOSバージョン、デバイス、製造元、通信事業者、ネットワークタイプを対象とする。
全数テストであり、市場で提供されているデバイス及びOSバージョンの数が多い場合、経済的観点からの採用できるものではない。

◇テスト戦略において、「外部リソース」の使用を考慮するケース

内部リソース（社内など）で対応できない場合、外部リソースを用いる場合もあると思います。
そのような場合のケースが以下となります。

・リモートデバイスアクセスサービス：
所有していないデバイスに、Webを介してアクセス

・クラウド（群衆）テストサービス：
大人数のボランティア及び彼らのデバイスにアクセスする手段を提供するサービス

・個人のネットワーク：
友人や同僚など、個人のプライベートソーシャルネットワークを活用するケース

・バグハンティング：
ゲーム化されたテストイベントで、企業または一般大衆からボランティアを活用するケース

□1.7モバイルアプリケーションテストの課題

こちらでは、モバイルアプリケーションの課題について取り上げられています。

◇モバイル分野での一般的な課題

・プラットフォームおよびデバイスの多様性（複数OS、バージョン、画面サイズ、ディスプレイの質）
・様々なデバイスのハードウェア上の相違（センサータイプ、CPU、RAMリソースの制約）
・プラットフォーム事に必要な開発ツールの多様性
・ユーザーインターフェースデザインとプラットフォームに期待されるユーザー操作性（UX）の多様性
・複数のネットワークタイプとプロバイダー
・リソース不足のデバイス
・アプリケーションの配布チャンネルの多様性
・ユーザーおよびユーザーグループの多様性
・アプリケーションのタイプと接続方法の多様性
・バグに起因するフィードバックの可視性の高さ
ユーザーに大きな影響を及ぼすバグが存在した場合、オンラインマーケットプレイスにフィードバックを公開できる
・マーケットプレイスでの公開：GooglePlaやApple Storeなどマーケットプレイス所有者の承認サイクルが余計に必要
・モバイルエミュレーター／シミュレーターの使用が必要となる新発売デバイスの使用可能性

（影響について）
上記一般的な課題に対して、影響を及ぼす内容を以下にまとめています。
・大量の組み合わせのテストが必要
・大量のデバイスをテストする必要があり、コストが上昇
・旧バージョンのプラットフォームでアプリケーションを実行するための下位互換の必要性
・オペレーティングシステムのバージョンごとにリリースされる新機能
・様々なプラットフォームで考慮が必要なガイドライン
・リソース不足のCPU、メモリとストレージ容量の制限
・様々なネットワークの帯域幅とジッター（時間軸方向での信号波形の揺らぎ）の多様性
・データ（契約）プランに基づく、アップロードとダウンロードの利用可能な速度の変化

□1.8モバイルアプリケーションテストのリスク

こちらでは、モバイル固有のリスクと、その軽減策について、まとめられています。

（JSTQB モバイルアプリケーションテスト担当者シラバスより）

「市場での多様なデバイス」のリスクにつては、モバイルアプリケーションの要件、設計書、仕様書等を参考に、「StatCounter GlobalStats」で軽減できると考えます。

■最後に

以上、JSSTQBシラバスモバイルアプリケーションテスト担当者の1項について紹介致しました。
次週は2項について、ご紹介したいと思います。
最後まで読んで頂き、ありがとうございました。

ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応

詳細はコチラをクリック！

【この1冊でよくわかる】ソフトウェアテストの教科書

詳細はコチラをクリック！