検索
連載

売れるスマホアプリを目指せ！ テスト達人への道：安藤幸央のランダウン（56）

「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部）

Share
Tweet
LINE
Hatena

売れるアプリを作るために重要な“使い心地”

　iPhoneやAndroidといった携帯電話端末が広まり、本記事の読者はもちろんのこと、通勤電車などでもごく普通にスマートフォンの利用者を見かけるようになりました。単に、iPhone・Androidアプリの利用者としてかかわっている人もいれば、実際にアプリの開発に携わっている人もいるでしょう。

　各種スマートフォンアプリを使っていて、何を感じるでしょうか？ さまざまなアプリの中にはシンプルで細かいところまで行き届いており、使いやすいアプリもあれば、遅くて使いづらく、頻繁に強制終了してしまうようなアプリまで、玉石混淆（ぎょくせきこんこう）です。

　さて、どんなアプリ開発者も、何もわざわざ使いづらい不安定なアプリが作りたいわけではありません。誰もが限られた予算と期間の中で、最大限「良い」アプリを作ろうと考えているはずです。

　しかし適切な「テスト」を経たうえでアプリをリリースしないと、想定しない事柄が起きたり、ユーザーにとって期待外れなものとなり、不安定なままで使ってもらうことになってしまいます。また、一度不便な印象を与えてしまうと、そのアプリを二度と使ってもらえなくなるかもしれません。

　そこで、より良いスマートフォンアプリを作るための、地味な作業ではありますが、大切な「テスト」に関していくつか取り上げていきましょう（本稿では、プログラマの作業範囲であるユニットテストに関する部分は含みません）。

テストの段階とアプローチ

　まず、テストにはいくつかの段階とアプローチがあります。

  1. 設計／UIデザイン／プロトタイピングの初期段階におけるテスト
  2. 開発中のテスト（実機とシミュレータ／エミュレータの違いを知るのが重要）
  3. 機能実装後の動作テスト
  4. 実機にテスト用アプリを入れて実際に使ってみるフィールドテスト
  5. 一般の方々に試用してもらうパブリックベータテスト
  6. リリース向けテスト（長期安定テスト／モンキーテストなど）
  7. リリース後、バグフィックス後の、アップデート版リリース時のテスト

　どの段階のテストも重要ですが、予算や期間の関係で、全てのテストを潤沢に時間と手間を掛けて実施できない場合もあります。プロジェクトの初期段階で、どのテストにどれくらいの時間と手間を掛けるのか、テスト計画を練っておくといいでしょう。テストにかかわる人数が多い場合、テスト計画そのもののスケジュール、不具合発見の報告のフローや、バグ修正後の再確認、テスト機の確保や分担など、細かく決めつつも、柔軟に変更しながら対応するのが得策です。

　Excelやバグトラッカーなどで、不具合報告番号、ビルド番号、不具合報告者、不具合の再現方法、不具合時の機種／OS環境、不具合の種別（見栄え、動作不良、文字の間違い）、不具合修正担当者、不具合修正の確認者など、面倒に思えても細々とした事象を記録しておくのが得策です。「ある特定の機種、特定のバージョンのOSでのみで発症するバグ」といったものも、よくあることです。

　テスト計画、テスト項目自身も、作成者だけではなく、関係者にレビューしてもらうと良いでしょう。

　上記のどの段階でのテストも、テストがゼロであれば、当然ながら不具合も1個も見つかりません。しかし、むやみに長時間テストをすれば大量のバグが見つかるというものでもありません。バランス良く、網羅的にテストできるよう考えましょう。

　一般的に、テストの初期段階で、多くのバグが洗い出され、時間をかければかけるほど、出現するバグは少なくなる傾向になるハズです（この傾向がなく、バグの発生数が収束しない場合は、実装段階で問題がある場合があります）。

　また、特にスマートフォンアプリの場合、1人の担当者だけで長時間テストするよりも、リーダーの下で何人かのテスト担当者が少しづつテストした方が、さまざまな視点で不具合を見つけやすくなります。

「テスト」は、2系統ある

　テストには大きく分けて2つの系統があると考えています。

　まず1つ目は、正しく動くということを確認するテスト、2つ目は多少無理を強いたり、普通はしないことを試して、うまく動かないことを見つけるテストです。

　ここで注意しなければいけないのは「うまく動くことを確認するテスト」は、そのアプリを開発した本人でも的確にテストできる種類のものです。その一方「うまく動かないことを見つけるテスト」は開発者本人は見落としがちです。

　テストのために初めてアプリを触ったテスターは「こう動くハズ」という前提なしに操作しますが、開発者本人は「こう動くハズ」というのを知っているために不具合を見つけづらい場合もあります。

　開発陣とテストする人が同じ場合は、いったん前提条件や操作方法を忘れて、意識的に別な人格として新しい気持ちでテストに挑んだ方が良い結果が生まれるようです。

スマートフォン固有のテスト、重点チェック項目

　スマートフォンアプリの場合、アプリ単独で動作する場合と、WebページやWebサーバと連携して動作するアプリなどがあります。

　大体のテスト項目はWebページ／Webアプリの要件が適応できます。その一方、以下のようにスマートフォン固有の重点テスト項目もあります。パソコンのWebブラウザで利用するサービスなどと比べ、開発そのものよりも、全体としてテストに手間が掛かるという印象があります。

□見た目・バージョン

　メニューなどの各種設定項目が、1つ1つ、それぞれのパラメータで機能するかどうかを確認しましょう。

　誤字脱字、スペルミスがないかどうか、大丈夫と思っていても、意外と間違いが残っているものです。

　将来的に、アプリをバージョンアップした際の、データの保存と継続性の確認も重要です。

□使いやすさ・ふるまい

　アプリ動作中に他の操作をした場合、正しい振る舞いをするのかチェックしましょう。他の操作とは、SMS通知が来た場合や、音量調整、ボイスコントロール機能などが該当します。

　バックグラウンドでの動作、またはバックグラウンドからの復旧の際の動作の確認も必要です。2分から5分で画面ロックが掛かった場合、そこからの復旧の振る舞いも確認しましょう。

　キー入力のテストも重要です。入力が必要なフィールドに実際に必要な文字／数値や、間違った文字／数値を入力して振る舞いを確認しましょう。多言語対応した場合は、それぞれの言語で表示と入力をチェックします。

　画面が縦向き、または横向きでの利用、または画面回転ロック状態での動作もチェックしましょう。

　意味もなく画面内のボタンや要素を適当に操作して、想定外の振る舞いがないかどうかチェックする「モンキーテスト」という手法もあります。左手での操作、右手での操作、両方を試すと、問題が浮かび上がる場合もあります。

□センサ・ネットワーク

　マナーモード時の音声出力の振る舞いも確認すべき項目です。それぞれの実機での正しい振る舞いに準ずるマナーモードでも、ヘッドフォンをつないでいるときは音楽が流れる機種もあります。

　3G携帯電話網やWi-Fi、ネットがつながっていないなど、さまざまなネット環境でのテストも必要です。アルミホイルなどで携帯端末を包み、電波を遮断してテストすると良いでしょう

　また、作成したアプリでGPSを使う機能を実装している場合ですが、GPS関連のチェックも必要です。GPSを切った状態でのテストとGPSを搭載していない機種でのテストが想定されます。

□パフォーマンス系

　ネットワークに関連して、3G携帯電話網でネットワークが途切れ途切れな、あまり良好でない状況でのパフォーマンスを確認しましょう。

　メモリが少ない状況での振る舞いのテストは必須です。バックグラウンドで多くのアプリを起動している場合、Webブラウザで多くのページを開いたままの状態などで動作確認しましょう。

　また、バッテリが残り少ないときの振る舞いも同じく必須項目です。バッテリの残りが少ないことによる警告などは、本体がつかさどるものですが、データが何らかの要因で正常に保存できなかった場合も、その保存できなかったデータが消失するだけで、アプリ全体が動かなくなるようなことがないようにチェックしましょう。

　長時間（大抵は数時間以上）動かし続けたときに不具合がないかどうかの「ストレステスト」も有効です。また、アプリ内で大量に新規データを作成したり、入力したり、限界点をチェックしましょう。

□セキュリティ

　Sign in（ログイン）／Sign out（ログアウト）時の振る舞いのテストや、パスワードが平文で保存されていたり、送信されていないか、操作だけではなく、プログラム内部で的確に扱われているのかを確かめましょう。

　特に、AndroidはiOSと違い、OS自体がオープンソースなうえに、Android Marketへのアプリ登録に審査がないので、セキュリティ的にも問題を多く抱えています。 Androidのセキュリティについては、以下の記事も参考にしてください。

最も悩ましいOS違い・機種違いのジレンマ

　各バージョンOSでの動作チェックも重要です。最新バージョンのOSで試すのは当然ですが、特に該当の携帯電話が発売されたとき、最初に入っている古いOSのバージョンをターゲットとする場合は特に念入りに確認しましょう。

　テスト機としていろいろなOSが用意できればベストですが、なかなかそうもいかないでしょう。一度OSを更新してしまうと、古いバージョンに戻せない場合が多いです。古いOSのものを更新せずにテスト機として持ち続けるか、古いOSのものはサポート外と割り切るのも1つの方法です。

　また、できれば日本語OS環境、英語OS環境、その他言語のOS環境について、日英以外の環境で、英語表示されるかをチェックしておきたいところです。

　予算や時間によってターゲットとする機種や、実機が用意できる機種にも限界がありますが、できるだけ多くの機種、多くのユーザーに使ってもらえることを考えましょう。ベータテスターを募ることも含め、できるだけ多くの実機で確認するのがいいでしょう。

　テスター向けに確認してほしいポイントをリストで伝える場合もあれば、何も説明せずに、試しに使ってもらい、分かりにくさや使いづらいところを報告してもらう案もあります。数世代前の古い機種でのテストもサポートするかどうかの明記も含めて確認すべきです。

　以下は多機種テストのポイントです。

  • まずは起動確認
  • 画面サイズの違いによる表示のずれがないか？
  • 色味の違い（特に屋外で日光の下で使っているときに、見やすさ／見にくさが顕著に分かる）
  • バックライトを控えめにした、画面が暗い場合でのチェック
  • 動作スピードの違い
  • 機能ボタンの配置や、キーボードやトラックボールがある機種もある点に注意
  • iOS系ではiPod touch、Android系ではタブレット端末に落とし穴がありがち
  • 最新OSではなく、発売当初の古いバージョンのOSで不具合がある場合も多い

　特に、多種多様なAndroid携帯端末、iOS系デバイスでは、画面サイズの違いもさることながら、カメラ機能やGPS機能など、ハードウェアに依存する部分は、全機種振る舞いが違うと覚悟した方がいいでしょう。

　日々多くのスマートフォン端末がリリースされる中で、全ての実機を取りそろえておくのは困難です。企業であれば、テスト機を貸し出してくれる有料のテストファームを利用したり、機密保持の下、社内でのパブリックベータテストを計画したりするのもいいでしょう。

　個人の開発者であれば、開発者同士、知人のつながりでアプリを試用してもらったり、早い段階でパブリックベータテストを始めるのも1つの方法です。

　実機テストについては、iPhoneアプリの記事ですが、以下も参考にしてください。

リリース直前のテストとリリース後のサポート

　最後に、デバッグ用のビルド番号表示やデバッグ用の何かが残っていないようチェックするとともに、デバッグ用の何かを削除したことによるさらなる不具合がないよう、さらに注意しなければいけません。

　アプリのリリースの際に、バグが「ゼロ」で出荷できればそれに越したことはありませんが、現実的には無理な場合もあります。想定外のバグではなく、回避策があり、軽微で既知のバグは、「Known Bugs」であるという認識の下でリリースするという判断もあります。

　また、100％完璧なテストはできないと考え、メールやWebなどによるサポート体制や、コミュニティによるサポート環境を構築するのも、より良いアプリへの道でしょう。

iPhone／iPadは、そもそも審査に通るかどうかも確認

　iPhone／iPadアプリの場合、開発者向けに「App Store Review Guidelines」という資料が公開されています。

　このリストのガイドラインに沿った形でないと、アプリとして動作としては不具合がなくとも、審査に通らず、アプリを修正しないとリリースできない場合もあるので、注意が必要です。

できるところは、自動化しよう

　Webブラウザ上のWebアプリのテストで知られる「Selenium」もバージョン2.0からAndroid上Webアプリのテストに使えるそうです。

　現状でも、Selenium風のツール「Robotium」が補助的に使えます（商用製品では、「Parasoft Mobile Test」というツールもあり）。

　また、アップルの開発環境であるXcodeに含まれるInstrumentsの「UI Recorder」を活用すると、一度操作したマウスの動きを記録し、シミュレータ上のテストを自動化できます。

　また、iOS SDK 4より、JavaScriptで記述したテスト手順によってUIの自動テストが可能な「UIAutomation」機能が搭載されました。この機能では、テストの途中に確認用のスナップショットを撮ることもできます。

　USB接続時は、実機でも自動テストが動きます。全自動で操作が進むので、手を撮影したくない、デモ動画撮影時にも活躍する機能です。

スマートフォンアプリの“テストの心得”

　スマートフォンアプリのテストの心得としていえることは、疑い深く対応し、安易な「大丈夫」は成り立たないと考えることです。必ず実機でのテストで確認することを習慣にすることです。

　開発の途中段階では、エミュレータやシミュレータでのテスト頻度が高いと思われますが、実機でなければできないテストとダミーの動作を上手に切り分けて行うのが得策です。

　特にネットワークの速度や、画面描画の速度、指による操作に起因するもの、GPSや各種センサーを利用したものなどは、実機でしか正しい確認はできません。

　実機によるテストは、その瞬間は面倒な手間を掛けて時間を無駄にするように思えますが、最終的には、実際に確認して積み重ねたことが品質の高いアプリを作ったという確信となるでしょう。

　次回記事は、2011年6月初めごろに公開の予定です。内容は未定ですが、読者の皆さんの興味を引き、役立つ記事にする予定です。何か取り上げてほしい内容などリクエストがありましたら、編集部や＠ITの掲示板までお知らせください。次回もどうぞよろしく。

Smart & Social
スマートでソーシャルなアプリ開発のための総合技術情報フォーラム

iPhone／iPadアプリ開発、Androidアプリ開発、携帯アプリ・モバイルFelica開発はもちろん、ソーシャルアプリ開発の情報もこちらへ、どうぞ

プロフィール

安藤幸央（あんどう ゆきお）

安藤幸央

1970年北海道生まれ。現在、株式会社エクサ マルチメディアソリューションセンター所属。フォトリアリスティック3次元コンピュータグラフィックス、リアルタイムグラフィックスやネットワークを利用した各種開発業務に携わる。コンピュータ自動彩色システムや3次元イメージ検索システム大規模データ可視化システム、リアルタイムCG投影システム、建築業界、エンターテインメント向け3次元 CG ソフトの開発、インターネットベースのコンピュータグラフィックスシステムなどを手掛ける。また、Java、Web3D、OpenGL、3DCG の情報源となるWebページをまとめている。

ホームページ
Java News.jp（Javaに関する最新ニュース）

所属団体
OpenGL_Japan (Member)、SIGGRAPH TOKYO (Vice Chairman)

主な著書
「VRML 60分ガイド」（監訳、ソフトバンク）
「これがJava だ! インターネットの新たな主役」（共著、日本経済新聞社）
「The Java3D API仕様」（監修、アスキー）


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る