こんにちは、品質管理グループの 山本久仁朗です。

みなさんの組織では、テスト対象端末(スマホ・タブレット・ガラケー・etc)を
選定する際に、どのように選定していますか？
選定方法によっては、不具合を発見するには、あまり効果的ではない
アプローチも多々あります。
今回は、我々の組織での機種選定方法について、お話いたします。

より効果的なテストを行うために

2016年3月末の内閣府の調査により、スマートフォンがガラケーの世帯保有数で
逆転したというニュースも記憶に新しいと思います。
http://www.nikkei.com/article/DGXLASDF08H0R_Y6A400C1EE8000/

いまでは多種多様なスマートフォンが発売されていますが、特に Android
は日本で発売された機種だけでも500機種以上存在しているために、
すべての機種でテストを実施するのは現実的ではありません。

しかし機種を選定するにしても、考慮すべき要素として OS Ver・メーカー・
解像度・メモリー・CPU・GPU・GPS・TV機能・ハイレゾ対応・各種センサーの
有無など、組合せが膨大にあります。
プロダクトリスクから、より効率的に動作保証しつつ不具合を検出するために、
効果的なテスト対象機種の選定方法を定義しておく必要があります。

機種選定のポイント

機種選定のポイントは、前述の通り多くの要素があります。
その中でも、アプリとウェブサイト（ブラウザアプリ）のテストを実施する際の
ポイントは、下記の項目を軸に考えるのがオススメです。
* 要素選定 * 優先順位付け * インパクトとスコープ * 機種選定

要素選定

OS バージョン

なぜ OS バージョンでの選定・網羅が必要なのか？
OS のメジャーバージョン・APIレベルに応じてOSの機能が大きくことなり、
表示・動作が異なる場合ために、プロダクトリスクに応じて、対象OS
バージョンの選定が必要になってきます。
具体的な例として、メジャーバージョンアップしたとたんに、アプリが
起動しなくなったり、特定の機能が使えなくなったりする場合があります。
その他にも、ウェブサイトの表示において特定のメンテナンスバージョンでのみ
JavaScript やウェブアプリが動作しない・表示しないという現象が発生します。

そのOSバージョンですが、iOS・Android の両OSにおいて、下記のように3段階の
レベルで表記されています。

【OS バージョン のレベル】

• XX.YY.ZZ
• XX ： メジャーバージョン
• YY ： マイナーバージョン
• ZZ ： メンテナンスバージョン(リリース、マイクロ 等と呼ばれる場合もある)

基本的に、発売時のバージョン、その後アップデート可能な各バージョン、
最新バージョンが各々存在します。
Android は、完全初期化を行うことで OS が出荷時のバージョンになる場合もあります。
iOS は、基本的にアップデートした場合、ダウングレード出来ません。
(ベータ版配信期間は、バックアップから復元することも可能な場合があります)

Android について、多くの日本メーカーのキャリアから発売されている機種の場合は、
キャリアから配信されるバージョンのみに限定されていますが、海外メーカーの場合は
キャリアに依存せずにバージョンアップできる機種があります。
最新のメジャーバージョン・APIを試すためには、海外メーカーの機種を使うことが多いです。
最近ではSIM フリー・格安スマホの台頭により、日本メーカーでも適時バージョンアップ
できる機種が発売され始めました。
また iOS の場合は、アップデート可能な機種の場合は Apple から配信される
タイミングで更新可能になりますので、非常に多くのバージョンが存在します。
ただし、基本的には各機種でアップデート可能な最新のバージョンにアップデート
可能なために、OSのシェアとしては Android ほどシェアが分散することはありません。
特に メジャーバージョンアップが行われた際には、アップデート可能なユーザーが
2週間程度で70%以上アップデートしているそうです。

メーカー

なぜ メーカーでの選定・網羅が必要なのか？
Android 端末は、メーカー毎にさまざまな違いがあり、主に HW と
SW(アプリ・OS・ファームウェア)の２つの側面があります。
HW については、アプリの機能によっては大きく影響を受けますが、
詳細は後述させていただきます。
SW の中でも個人的に Web系のサービスにとって特に影響が大きいのは、
Android 4.3(4.1-4.3:Jelly Bean)以前の、AOSP Stock Browser
(通称 Android標準ブラウザ)をベースの「ブラウザ」アプリの存在です。
「ブラウザ」アプリは、各メーカーで独自実装(魔改造？)をしているために、
動作が異なる場合があります。スマートフォン向けのサービスを開発・提供
している方々なら、特定の機種・メーカーのデバイスだけ下記のような話を
聞いたことがあると思います。
Android 4.4(KitKat)から、代わりに Chrome WebView が提供されるように
なり独自性は少なくなったようです。

【標準ブラウザ起因の不具合】

• JavaScript の特定の機能が動かない
• WebView で画像が表示されない(白画面)
• 画面遷移が行われない
• etc

【主要メーカー】

• ソニー
• 京セラ
• シャープ
• LG
• HTC
• サムスン
• 富士通
• Apple

画面解像度

なぜ 画面解像度での選定・網羅が必要なのか？
Android・iOS の両方で起きる問題として、小さい画面において文字・ボタン・
バナー等のアイテムが見切れてしまったり、レイアウト全体が崩れてしまったり
する場合があります。　大きい画面においてはスマートフォンでPC版のページを
見たときのように、文字やボタンが小さすぎて見づらい操作しづらい等の問題が
発生します。
ここ数年 Full HD(1920×1080)が最も主流になっているために、iPhone4S(960×640)や
Androdi2.3・4.0系(800×480)でチャット等のコミュニケーション機能を使おうとすると、
キーボードが表示されるとメッセージ・画面が見えなくなってしまうなども発生します。

【主要画面解像度】(採用機種数順)

• 1920 × 1080
• 1280 × 720
• 960 × 540
• 800 × 480
• 2560 × 1440
• 1136 × 640
• 960 × 640

内部メモリ容量

なぜ内部メモリ容量での選定が必要なのか？
内部メモリ容量のサイズによっては、特定の機種ではアプリ自体が起動出来ない・
使用しているとメモリが枯渇して落ちる場合があるからです。
最近は、スマートフォンの性能が向上していますので、あまり気にならなくなって
きていますが、Android 2.3 系の端末はほとんどが 512MB という容量だったために、
OS と標準アプリが動作すると 100MB 程度しか空きがなくなってしまいました。
メモリ容量が少なければ、初期動作をしても使い続けるうちに動きが遅くなり、
時には強制的に終了したりする場合もあります。
そんなこともあってか、Android には多くのタスク管理アプリがあり使っていない
アプリ・メモリ領域を止めたり開放したりする必要がありました。

【Android OS毎の主流メモリ容量】

• Android 2.x　：　0.5 ～1.0 GB
• Android 4.x　：　1.0 ～3.0 GB
• Android 5.x　：　2.0 ～3.0 GB
• Android 6.x　：　2.0 ～4.0 GB

CPU

なぜ CPU での選定が必要なのか？
アプリなどは CPU の性能により動作・ユーザー体験が大きく変わります。
端末によっては性能が低すぎてサービス・UXとして成り立たない場合があります。
また最近はほとんど影響がなくなってきていますが、CPUのブランドによる動作の
違いもあります。　特に Android 2.x～4.0.x が主流だった時期にスマホの
サービスに関わっていた方らならば、特定のCPU・チップセットで問題が発生する
という現象を経験をした人は少なからず、いらっしゃるのではないでしょうか？
現状 Qualcomm・Snapdragon・Mediatek の ARM系アーキテクチャのブランドが
非常に強いですが、ASUS・Lenovo等の PC系のメーカーは Intel Atom プロセッサーを
採用しているようです。

• 例：ビリヤードなどのゲームで、物理演算と描画が間に合わなくて、
  コマ落ちしてしまい球の軌道がまるでわからないために、ゲームとして成り立たない

キャリア回線

なぜキャリア回線での選定が必要なのか？ とくにキャリア回線のうち、4G(LTE)・3.9G(WiMAX等)と3Gでは、下記のような
違いが有り、速度・つながりやすさ等要因で様々な不具合が発生します。
また、メーカーやキャリア回線だけではなく Wi-Fi を併用した場合の弊害もあります。
さらに、各キャリア毎に使用量の上限になった場合の制限速度も異なります
( 64K ～ 256Kbps )ので、スコープによっては検討する必要があります。

【4G(LTE) と 3G の違い】

• 4G：
  • 速度 速い(75～100Mbps程度)
  • エリア 拡大中
• 3G：
  • 速度 遅い(数～14Mbps程度)
  • エリア 人口カバー率が、ほぼ100%

特殊なデバイス条件

カメラなし端末

最近はほとんどないと思いますが、Android タブレットの中には、カメラデバイスが
存在しない端末もあります。
SNS・ECアプリ等でカメラを起動して画像をアップする機能を有するものもありますが、
カメラを認識しないとエラーとなりローカルストレージの画像も取り込めなくなって
しまうアプリも幾つか存在しているようです。

SDカードがないと、画像を取れない

Android 4.0.x 以前の機種に存在しますが、アプリ内でカメラを使用した場合に
画像を保存できずにエラーになる場合があります。

キーボード付き

こちらも最近ほとんど見なくなりましたが、スマートフォンはスライドして
キーボードが出てくるタイプには、テンキーとフルキーボード等があります。
キー入力等をする際に、画面内にキーボードが表示されないことなど、
確認できると良いですね。

2画面

ごく一部のスマートフォン・タブレット端末で2画面を採用して、
「折りたためる」ことをコンセプトにしている機種があります。
特別な問題は、ほとんど発生しませんが画像・文字が見切れる、
見づらい等の課題があるようです。

ハイレゾ対応

ハイレゾとは「ハイレゾリューション・オーディオ」（高解像度音源）の略
ですが、音楽再生アプリにおいてハイレゾ音源データを再生できるか非常に
重要だと思います。
もちろんハイレゾ非対応のスマホでも通常音源データを再生できることも
必須だと思います。

フルセグ対応

ここ数年、ワンセグだけでなくフルセグ対応の機種も増えています
(30機種弱)、ワンセグとフルセグの違いは簡単に言うとワンセグの
ほうが受信しやすく録画サイズが小さい、フルセグのほうが画像が
きれいというところですが、アプリによっては、ワンセグ・フルセグの
自動切り替え等の様々な機能を有しています。　ほとんどの端末が
TV録画アプリがプリインストールされていますので、端末選定の要素に
なることは少ないと思います。

その他にも、下記のような多くの要素(デバイス・性能)が存在しますが、
プロダクト・サービスのテスト目的に応じて必要な要素を選定してください。

• 例：GPS・モーションセンサー・ジャイロセンサー・カメラ機能
  (解像度・感度・シャッター速度・望遠・オートフォーカス・顔認証)
  ・指紋認証・NFC・防水・etc

優先順位(リスク)付け

テクニカル・プロダクトリスクの観点

プロダクト・サービスを実現・継続するために、重要な機能から外せない
要素(SW・HW)を選定する必要があります。
JavaScriptをバリバリ使って実装している場合、ブラウザ・OS Version 等は、
考慮が必須になります。
また、リッチなネイティブアプリの場合は、CPU(・GPU)や内部メモリの考慮が
必須になると考えます。

ビジネスリスクの観点

ビジネスリスクとして、利用者の環境・ユースケースを考慮する必要があります。
企業向けのサービスで、社内 Wi-Fi 経由のみでの利用が想定している場合は、
キャリア回線が対象外になるでしょう。
またサービス対象のキャリアが限定される場合は、対象のキャリア回線で実施
しなけば必須となります。
後述します、ビジネスインパクトとして各種シェアも観点抽出には重要な
ファクターになります。

インパクトとスコープ

インパクト

前述の優先順位付けで抽出した要素から、下記のような各種シェア＆KPIを
ベースに各要素から対象を選定します。
近年ではユーザー行動などを解析してデータマイニングなどして、より効果的な
要素を選定している組織も多いのではないでしょうか。

• 各種シェア
• 端末シェア(製造台数・販売台数・etc)
• UU(ユニークユーザー数)
• PP(ページビュー数)
• DAU(デイリーアクティブユーザー：1日の利用者数)
• MAU(マンスリーアクティブユーザー：1ヶ月の利用者数)
• KPI
• ARPU(ユーザー1人あたりの平均売上金額)
• CVR(コンバージョンレート：広告参照後に購入・資料請求に至る割合等)

スコープ

インパクトと一緒に考えることが多いともいますが、技術＆ビジネス
リスクからインパクトを算出・想定して、どの程度の範囲・粒度を
品質保証範囲としたいのかに応じて、スコープは変わります。
例えば、過去の事例や技術的な要素から、デバイスの考慮が不要で
OS Version もメジャーなものをカバーすれば良いとなるとかなり
機種数が絞られると思います。
別の考え方として、毎月の売上が数十億円以上のサービスの場合は、
技術リスクが低くてもビジネスインパクト的にスコープを広げる必要が
出てくると思います。

機種選定

上記の優先順位付けで選定した要素(SW・HW)とスコープの組合せで、
具体的な機種を選定します。
我々の組織では、下記のような機種数で実施しています。
プロジェクト・プロダクトの状況に応じて、下記のように1つの
プロジェクトの中で、複数のスコープを組み合わせる場合があります。

• 機種選定とテスト目的の組合せの例
• 全機種　　 ： 起動終了＆メイン機能1回実施
• メインパス ： OS マイナーバージョン & メーカー & 主要ブラウザ
• 既存機能　 ： OS メジャーバージョン

我々のチームでは、au端末での確認を主なサービスとしておりますので、
下記のようにレベル分けしプロジェクトに合わせて機種選定しています。

例えば、下記のような組合せで実施しています。

• 新規アプリの場合

  • 起動終了＆主要機能：全機種(レベルA：120端末)
  • 各機能確認：OS×メーカー(レベルE：16端末)

• 既存アプリでWebView関連改修の場合

  • 各面・機能確認：OS×メーカー（×２）(レベルD：32端末) (各開発コードで、標準ブラウザを網羅する)

• 新規Webサイト(ブラウザゲーム等も含む)

  • 各面・機能確認：OS × ブラウザ(レベルJ：20端末)

まとめ

テスト目的に合わせて、機種選定をしないと抜け漏れが発生するだけではなく、
無駄な工数が発生してしまいます。
みなさんも、もう一度機種選定方法を見直しては如何でしょうか？

もしかするとテスト工数が効果的に削減できるかもしれません！

より良いプロジェクト運営の一助になれば幸いです。