ここが超タイヘンだよAndroidアプリのシステムテスト：Androidアプリ開発テスト入門（7）（2/3 ページ）

[生路茂太，日本Androidの会テスト部]

Androidアプリにおけるシステムテストの難しさ

　スマホだけでも年に数回コンスタントにリリースされるAndroid製品は、それぞれが商品として自社の旧製品や他社の製品と「差別化」されています。グーグルからリリースされるAndroidのバージョン差分との組み合わせで膨大な端末差分が発生しています。

　こうした差分は、「商品の差別化」という商売の原則から発生している問題です。単一メーカーの製品であるiPhoneでさえも過去機種との差分が発生するのですから、Androidのアプリ開発者としては差分が発生し続けること自体は受け入れるしかありません。

フィーチャーフォンやWindowsの良さ

　「フィーチャーフォンのときは、ここまでひどくなかったのに……」と思うかもしれませんが、当時はキャリア・メーカー・ソフトウェアベンダで動作差分が起こらないように、膨大なシステム試験を含めた擦り合わせ作業を頑張っていたのです。

　「でもWindowsだってこんなこと起こらないじゃないか」と思うかもしれませんが、Androidはセンサやディスプレイサイズなどのハードウェアデバイスで差別化を図ることも多いため、「原因がAndroidソフトウェア上にない場合がある」ことが問題を複雑にしています。

「端末フラグメンテーション問題」と呼ばれる現象

　Androidの機種差分が引き起こすアプリの問題を、「端末フラグメンテーション問題」と呼ぶことはご存じかと思います。端末の差分から発生するすべての問題を「端末フラグメンテーション問題」と呼んでいるため、厳密に特定ができないのですが、次のような事例があるようです。

1. カメラの撮影サイズ
2. 液晶のサイズ／アスペクト比
3. 搭載OSのバージョンによる機能の違い
4. 端末のハードウェア性能による振る舞いの違い

　液晶サイズやOSのバージョンごとの振る舞いの差異のように、ある程度エミュレータでテスト可能なものもあります。しかし、商用出荷直前のアプリである場合など、やはり実際の端末で動作を確認しないと不安に思うのではないでしょうか。しかし、手元には数台の端末とエミュレータしかない場合は多端末を対象にしたシステムテストのやりようがありません。

多端末テスト環境の整備

　こうした実機依存のシステムテストへの1つの解として、多様なAndroid実機端末の動作確認を遠隔で実行できるサービス（以下、「リモートデバイスコントロールサービス」とします）を導入することが有効です。高コストな多端末向けシステムテストを現実的なコストで実現できます。

「リモートデバイスコントロールサービス」とは

　リモートデバイスコントロールサービスは、国内外数社から商用サービスが提供または提供準備されています。先日のAndroidテスト部主催「第二回Androidテスト祭り」では、商用サービスの担当者が登壇し、各社サービスの特徴をプレゼンしていました。

　各社に共通していることは、サービス元に準備されたAndroid端末に対して、遠隔からリモート操作できることです。操作できる範囲は、各社ごとに特色がありますが、apkファイルをインストールしてアプリの動作確認を行うことがサービスの中心です。

リモート環境とローカル環境の役割分担

　リモートデバイスコントロールサービスによる多端末テスト環境は強力なメソッドであることは確かです。しかし、会社により得手不得手はありますが、概ね以下のようなテスト項目を苦手としています。

• GPS、音声などを利用したハードウェアに依存するテスト
• 加速度などの物理的に端末を「動かす」テスト
• Bluetoothや赤外線などの通信相手が必要な対向テスト
• マウス操作、遠隔操作のため、ユーザーの「肌感」を試すような感覚的なテスト

　また、当然ですが時間単位でコストが発生しますし、サービス提供側の端末も無限ではないので「先客がいたら使えない」ということもあり得ます。自動化できないことを十分把握したうえで、手元実機で必要な手動テストを経て自動化が可能な範囲を多端末で実施し、効率化が図れる範囲を見極めたうえで上手に利用することが重要です。

ユーザーフィードバックのメトリクス的な活用

　このように、多端末を意識した設計、自動テストを用いた十分なユニットテスト、リモート環境による多端末テストにより、リリース前に実行可能な最善の努力を行ったとします。

　それでも、実際の利用者に100％満足してもらえるわけではありません。リリース後に、システムを実際に利用するエンドユーザーのクレームや、アプリを購入したマーケットから上がってくるコメントなどのユーザーフィードバックは、どのように扱うべきでしょうか。

　リリース後のユーザーフィードバックには、以下の3つの意味があると思っています。

1. 一般的な意味の「テスト項目漏れ」
2. コストの問題により断念した多端末テストに事後対策
3. ユーザーとベンダの認識のそもそもの違いによる「動かない」問題への対策

　ここでいう「動かない」とは、「期待していたほど動かない」という定性的なものです。機能的には問題ないですが、特定の状況でインタラクションが遅いなどの問題もユーザーにとっては「動かない」問題です。

　こうした事後対応のプロセスは、「検収前のシステムテスト」ではありません。しかし、そもそも「端末フラグメンテーション問題」の根本解決が不可能なのですから、リリース後のユーザーフィードバックも「次期リリースに向けたシステムテスト」と見立てて、活用していくべきだと考えます。

DIKWモデルによるユーザーフィードバック活用の4手順

　ユーザーフィードバックの活用のプロセスについて、「DIKW」という情報工学の考え方を元に整理してみたいと思います。DIKWとは「Data」「Information」「Knowledge」「Wisdom」の頭文字を取った略語です。それぞれ以下のような意味を持っています。

1. Data（データ）：未編集の状態
   例）整理されていない大量のアプリレビューコメントなど
2. Information（情報）：“データ”の属性が整理分類された状態
   例）利用環境、ユーザー像、問題種別などが特定された情報
3. Knowledge（知識）：“情報”同士の原因と結果が分析された状態
   例）ある端末では特定の問題が起きる
4. Wisdom（知恵）：“知識”が総合されて判断基準となった状態
   例）「○○機能は実装するな」

情報の形態 - Wikiウサギ - ドブロク[DOBUROKU] via kwout

　ユーザーフィードバックは、ソーシャルネットワーク／SNSやアプリレビューなどによりデータを集めることから始まります。集めたデータは、分析を経て属性付けされて意味のある情報に加工されます。この情報同士から、原因と結果の関係を発見することで知識化を行い、最終的に経験的な判断基準である知恵の修得を目指すものです。ここでいう「知恵」とは何かというと、筆者は「ことわざ」に近いものだと理解しています。

　例えば、「早起きは三文の得」と言われても、早起きと経済的利益の間には直接の相関がありません。しかし、このことわざの成り立ちは、大量の経験（ビッグデータ）の蓄積から長い時間を掛けて相関を取ったために、傾向が見えたのではないでしょうか。ユーザーフィードバックは、DIKWによってより効率的に新しい成功方程式となる「ことわざ」を発見するプロセスというイメージです。

　次ページでは、実際のデータを使ってDIKWプロセスを紹介します。