Contenu connexe
Similaire à smartphone test (know how & tools)
Similaire à smartphone test (know how & tools) (20)
smartphone test (know how & tools)
- 1. Androidは、Google Inc.
これだけはやっておきたい の⽶米国およびその他の国に
おける登録商標です。
スマートフォンを成功に導く iOS, iPhoneは、Apple
Inc.の⽶米国およびその他の
国における登録商標です。
テストの極意 その他すべての会社名・製
品名・サービスネームは、
それぞれ各社の商標または
多機種対応の勘所や 登録商標もしくはサービス
マークです。
品質向上効果の高い
ツール活用のヒント
株式会社エクサ/ユビキタスPCMソリューション部
安藤幸央
2012.7.13 14:35∼15:15
@yukio_andoh yukio-ando@exa-corp.co.jp
all images : Flickr (CC)
2012年7月13日金曜日 1
- 2. アジャイル
スマートフォン 使ってますか？
2012年7月13日金曜日 2
- 5. 品質向上
≒
いかにテスト
するか？
2012年7月13日金曜日 5
- 6. プロトタイピング 設計 開発・実装 テスト
Webサービス
スマートフォン
0 25 50 75 100
2012年7月13日金曜日 6
- 7. 多様な機種
多様な利用者
多様な状況
2012年7月13日金曜日 7
- 11. テストの段階とアプローチ
1. 設計／UIデザイン／プロトタイピングの初期段階におけるテスト
2. 開発中のテスト（実機とシミュレータ／エミュレータの違いを知るのが
重要）
3. 機能実装後の動作テスト
4. 実機にテスト用アプリを入れて実際に使ってみるフィールドテスト
5. 一般の方々に試用してもらうパブリックベータテスト
6. リリース向けテスト（長期安定テスト／モンキーテストなど）
7. リリース後、バグフィックス後の、アップデート版リリース時のテスト
2012年7月13日金曜日 11
- 12. テスト計画
1. テストにどれくらいの手間と費用、時間をかけるか？
2. テストに関わる人員（選任、開発者、試用ユーザー）
3. 不具合発見∼報告へのながれを構築。不具合情報の共有
4. バグ修正後の再確認
5. テスト機器の確保や分担
6. 既知のバグ（対応を見送るものの判断）
7. リリース基準（品質の確保）
2012年7月13日金曜日 12
- 13. バグトラッカーでの管理
通し番号 不具合修正の担当者
ビルド番号 修正完了したビルド番号
不具合報告者 不具合修正の確認／承認者
不具合の再現方法 バグ収束曲線
不具合発生時の機種／OS環境 バグ発生率
不具合の種類（見栄え、動作
不良、文字の間違い）
※テストアプリにビルド番号表記
2012年7月13日金曜日 13
- 14. 客観視
テストのアプローチ
1. テスト計画、テスト項目を早めの段階で作成
2. 具体的な利用シーンを想定したユースケースに応じたテスト
3. 開発の初期段階でできるだけ多くの不具合を洗い出す
4. 不具合が見つかって、その対応が複雑な場合は、シンプルに
5. 一人で長時間テストするよりも、多くの人数で、網羅的に
6. 開発者は「正しく動く」ことをテストするのには向いている
7. 手順の定常化。常に工夫し続ける。慣れを過信しない。
2012年7月13日金曜日 14
- 16. 指
タッチパネルを指で操作
指で触れるサイズのもの
触ったものは指で隠れる
2012年7月13日金曜日 16
- 17. 見た目・バージョン
メニュー項目、画面上の文言に間違いがないか複数の目で
紙でチェック（多言語の場合は特に念入りに, 日英以外も）
各メニューの項目がそれぞれ動作するか、画面フローをも
とに網羅的にチェック。フォーム入力域に様々な値を入れ
てチェックする。（ソフトウェアキーボードで画面の半分
くらい隠れるため、念入りに）
将来的にアプリをバージョンアップする予定がある場合、
データの永続性や、バックアップ方法を確認しておく
2012年7月13日金曜日 17
- 18. 使いやすさ・ふるまい
電話としての様々な機能と共存しているのかチェックする。
SMS着信、電話着信、音量調整、ボイスコントロールなど
バックグラウンドでの動作、バックグラウンドからの再開、
画面ロック後、ロック解除後のふるまい
キー入力関連のテスト。不要な文字、絵文字、間違った数
値、多言語入力のチェック
画面の縦向き、横向きでのチェック。左手右手での操作。
2012年7月13日金曜日 18
- 19. センサ・ネットワーク
マナーモードでの音声、バイブレーションの振る舞いの確認
3G携帯電話網での利用、WiFiでの利用でのチェック。特に
データ流量や待ち時間に注意。
地下鉄などの電波が遮断される環境を想定してのチェック。
都心の地下鉄の場合は2∼3分の遮断時間。アルミホイルで！
GPS位置情報機能のチェック。GPS OFF時の振る舞い。バッ
テリーの消費量も重要な確認項目
2012年7月13日金曜日 19
- 20. パフォーマンス
ネットワークが極端に遅い、または頻繁に断絶するような環
境を考えたチェック。データが失われずリカバリできるよう
利用メモリが少ない状況での動作チェック。Webブラウザで
複数画面を開いているような場合が該当します。
バッテリーが少ない状況。アプリ利用中にバッテリーがなく
なった場合でもデータ等が失われたり壊れたりしないよう。
長時間利用における安定度テスト、ストレステスト
大量に新規データを作成したり大量に入力したり限界点確認
2012年7月13日金曜日 20
- 21. セキュリティ
サインイン（ログイン）、サインアウト（ログアウト）など
の確認。わざと間違えた時の振る舞いの確認など
内部データの保存形式などをソースコードレベルで確認する
セキュリティの専門家に脆弱要素を指摘してもらい確認する
そもそも脆弱要素のあるサービスにしない（個人情報は持た
ずに Twitter, Facebook によるログイン形式にするなど）
Android アプリの脆弱性に関するレポート（IPA）が役立つ
2012年7月13日金曜日 21
- 22. 多機種対応の
勘所
2012年7月13日金曜日 22
- 23. ターゲットを設定
1. リファレンスとなる1∼2機種を規定
（ブランド、キャリア、ターゲットにするユーザー層により）
2. 多くのキャリアでは2年契約：現行機種から二年前の機種まで
3. 発売時に搭載されていた OS （そのまま使い続けている人）
4. 現在の最新OS環境（バグが少なく理想的な環境）
5. 古い機種／古いOSがそろえられない場合が多い
6. テストラボ（キャリア、専門企業が提供する機器借用環境）
2012年7月13日金曜日 23
- 24. 多機種対応の範囲
1. リファレンス機での 100% のテスト
2. それ以外の機種で必要な最低限のテスト（10∼20%程度）
3. 対応機種と、対応外の機種を明確に設定
4. 一般リリース後に報告をもらう体制、不具合機種への対応策
5. ハードウェア固有の要素を重点的に
画面サイズ、カメラ機能、動画再生
ハードウェアキー、各種センサー、GPS位置情報
2012年7月13日金曜日 24
- 25. 多機種対応の実際
1. まっさらな状況から、インストール確認
2. 起動確認（ネットワークの有無に影響される場合もあり）
3. 画面サイズの違いによる表示のずれがないか？
4. 文字サイズの設定の違いによる表示のずれがないか？
5. 画面の色味の違いが無いか？（青っぽい？屋外での見え方）
6. 動作スピードの違い、アニメーション、滑らかな動きか？
2012年7月13日金曜日 25
- 26. 守秘義務
多機種対応の作戦 前提
1. まずは開発者当人らが長時間いろいろな場面で使い込む
2. 多くの周りの関係者にベータテストユーザーになってもらう
3. 家族や知り合いなどにベータユーザーになってもらう
4. 一般ユーザーを募集して、初期試用してもらう
5. 初期リリース時、可能であれば、利用人数に制限を設ける
6. リリース時に大々的に宣伝・告知せず様子を見る。ある程度
安定し、初期ユーザーが満足してからリリースでも遅くない
2012年7月13日金曜日 26
- 27. リリース後が本番
1. リリース時にデバッグ用の何かが残っていないように
2. デバッグ用の何かを削除したために不具合がおきないように
3. バグゼロは難しい。既知のバグを把握した上でリリースする
4. 一般ユーザーからバグ報告を受ける時用にバージョン表記
5. メールやWebによるサポート体制（比較的小規模で良い）
6. スマートフォンアプリの利用者コミュニティーを構築する
7. 利用している外部APIのバージョンアップに目を光らせる
2012年7月13日金曜日 27
- 28. Tools
&
Books
2012年7月13日金曜日 28
- 30. Adobe Shadow 複数機種を
一度に確認
http://labs.adobe.com/technologies/shadow/
2012年7月13日金曜日 30
- 31. iScreen 画面を転送
http://www.drahtwerk.biz/EN/Home.aspx 実機確認
2012年7月13日金曜日 31
- 32. リモートスマホレンタル 遠隔地の
実機を試用
http://www.katomakku.com/
2012年7月13日金曜日 32
- 33. Android
開発者メニュー
テストやデバッグの
助けとなる各種機能
2012年7月13日金曜日 33
- 34. GORILLA
LOGIC
http://www.gorillalogic.com/
iOS用。機能テストを自動
化するツール。操作記録、
再生、自動テスト用のスク
リプト記述ができる。モン
キーテストにも利用可。
2012年7月13日金曜日 34
- 35. TestFlight(iOS)
https://testflightapp.com/
ベータ版のテストアプリを
多くのベータユーザーに平
易に届け、的確なフィード
バックを得られる仕組み
2012年7月13日金曜日 35
- 36. iPhoneアプリ設計の極意
思わずタップしたくな
るアプリのデザイン
http://www.oreilly.co.jp/
books/9784873115023/
2012年7月13日金曜日 36
- 37. Android Application
Testing Guide
http://www.packtpub.com/
android-application-testing-
guide/book
2012年7月13日金曜日 37
- 38. ソフトウェアテスト
293の鉄則
http://ec.nikkeibp.co.jp/item/
books/P81540.html
2012年7月13日金曜日 38
- 40. 公式資料を参照
Android 標準のガイドライン
http://developer.android.com/design/index.html
iOS ヒューマンインターフェイスガイドライン
https://developer.apple.com/jp/devcenter/ios/library/documentation/
MobileHIG.pdf
Windows Phone ユーザエクスペリエンスガイドライン
http://msdn.microsoft.com/ja-jp/library/hh202915(v=vs.92).aspx
2012年7月13日金曜日 40
- 41. まとめ
実機テスト最重要
すべてを疑う
あらゆる状況を想像
2012年7月13日金曜日 41
- 42. モバイルアプリの
初期バージョンは
必ず失敗する
Dave Morin (Path CEO)
User Experience 重要
行動パターンの見極め
シンプル／フォーカス
テーマ設定で意思統一
膨大なデザイン修正
2012年7月13日金曜日 42
- 44. Thank you !
yukio-ando@exa-corp.co.jp
2012年7月13日金曜日 44
- 64. 失敗した時は、
なぜかではなく回避方法を
2012年7月13日金曜日 64
- 66. エキスパートに
なったかのような気分に
2012年7月13日金曜日 66
