Embed Size (px)
DESCRIPTION
Citation preview
これだけはやっておきたいスマートフォンを成功に導くテストの極意
多機種対応の勘所や品質向上効果の高いツール活用のヒント
株式会社エクサ/ユビキタスPCMソリューション部
安藤幸央
2012.7.13 14:35～15:15
@yukio_andoh [email protected] images : Flickr (CC)
Androidは、Google Inc.の⽶米国およびその他の国における登録商標です。 iOS, iPhoneは、Apple Inc.の⽶米国およびその他の国における登録商標です。その他すべての会社名・製品名・サービスネームは、それぞれ各社の商標または 登録商標もしくはサービスマークです。
12012年7月13日金曜日
アジャイルスマートフォン 使ってますか？
22012年7月13日金曜日
一人約200アプリ。よく使うのは10個
32012年7月13日金曜日
いつでも、どこでも使うもの
42012年7月13日金曜日
品質向上
≒いかにテストするか？
52012年7月13日金曜日
Webサービス
スマートフォン
0 25 50 75 100
プロトタイピング 設計 開発・実装 テスト
62012年7月13日金曜日
多様な機種多様な利用者多様な状況
72012年7月13日金曜日
82012年7月13日金曜日
92012年7月13日金曜日
102012年7月13日金曜日
テストの段階とアプローチ1. 設計／UIデザイン／プロトタイピングの初期段階におけるテスト
2. 開発中のテスト（実機とシミュレータ／エミュレータの違いを知るのが重要）
3. 機能実装後の動作テスト
4. 実機にテスト用アプリを入れて実際に使ってみるフィールドテスト
5. 一般の方々に試用してもらうパブリックベータテスト
6. リリース向けテスト（長期安定テスト／モンキーテストなど）
7. リリース後、バグフィックス後の、アップデート版リリース時のテスト
112012年7月13日金曜日
テスト計画1. テストにどれくらいの手間と費用、時間をかけるか？
2. テストに関わる人員（選任、開発者、試用ユーザー）
3. 不具合発見～報告へのながれを構築。不具合情報の共有
4. バグ修正後の再確認
5. テスト機器の確保や分担
6. 既知のバグ（対応を見送るものの判断）
7. リリース基準（品質の確保）
122012年7月13日金曜日
バグトラッカーでの管理通し番号
ビルド番号
不具合報告者
不具合の再現方法
不具合発生時の機種／OS環境
不具合の種類（見栄え、動作不良、文字の間違い）
不具合修正の担当者
修正完了したビルド番号
不具合修正の確認／承認者
バグ収束曲線
バグ発生率
※テストアプリにビルド番号表記
132012年7月13日金曜日
テストのアプローチ1. テスト計画、テスト項目を早めの段階で作成
2. 具体的な利用シーンを想定したユースケースに応じたテスト
3. 開発の初期段階でできるだけ多くの不具合を洗い出す
4. 不具合が見つかって、その対応が複雑な場合は、シンプルに
5. 一人で長時間テストするよりも、多くの人数で、網羅的に
6. 開発者は「正しく動く」ことをテストするのには向いている
7. 手順の定常化。常に工夫し続ける。慣れを過信しない。
客観視
142012年7月13日金曜日
チェック項目
152012年7月13日金曜日
指
タッチパネルを指で操作
指で触れるサイズのもの
触ったものは指で隠れる
162012年7月13日金曜日
見た目・バージョンメニュー項目、画面上の文言に間違いがないか複数の目で紙でチェック（多言語の場合は特に念入りに, 日英以外も）
各メニューの項目がそれぞれ動作するか、画面フローをもとに網羅的にチェック。フォーム入力域に様々な値を入れてチェックする。（ソフトウェアキーボードで画面の半分くらい隠れるため、念入りに）
将来的にアプリをバージョンアップする予定がある場合、データの永続性や、バックアップ方法を確認しておく
172012年7月13日金曜日
使いやすさ・ふるまい電話としての様々な機能と共存しているのかチェックする。SMS着信、電話着信、音量調整、ボイスコントロールなど
バックグラウンドでの動作、バックグラウンドからの再開、画面ロック後、ロック解除後のふるまい
キー入力関連のテスト。不要な文字、絵文字、間違った数値、多言語入力のチェック
画面の縦向き、横向きでのチェック。左手右手での操作。
182012年7月13日金曜日
センサ・ネットワークマナーモードでの音声、バイブレーションの振る舞いの確認
3G携帯電話網での利用、WiFiでの利用でのチェック。特にデータ流量や待ち時間に注意。
地下鉄などの電波が遮断される環境を想定してのチェック。都心の地下鉄の場合は2～3分の遮断時間。アルミホイルで！
GPS位置情報機能のチェック。GPS OFF時の振る舞い。バッテリーの消費量も重要な確認項目
192012年7月13日金曜日
パフォーマンスネットワークが極端に遅い、または頻繁に断絶するような環境を考えたチェック。データが失われずリカバリできるよう
利用メモリが少ない状況での動作チェック。Webブラウザで複数画面を開いているような場合が該当します。
バッテリーが少ない状況。アプリ利用中にバッテリーがなくなった場合でもデータ等が失われたり壊れたりしないよう。
長時間利用における安定度テスト、ストレステスト
大量に新規データを作成したり大量に入力したり限界点確認
202012年7月13日金曜日
セキュリティサインイン（ログイン）、サインアウト（ログアウト）などの確認。わざと間違えた時の振る舞いの確認など
内部データの保存形式などをソースコードレベルで確認する
セキュリティの専門家に脆弱要素を指摘してもらい確認する
そもそも脆弱要素のあるサービスにしない（個人情報は持たずに Twitter, Facebook によるログイン形式にするなど）
Android アプリの脆弱性に関するレポート（IPA）が役立つ
212012年7月13日金曜日
多機種対応の勘所
222012年7月13日金曜日
ターゲットを設定1. リファレンスとなる1～2機種を規定
（ブランド、キャリア、ターゲットにするユーザー層により）
2. 多くのキャリアでは2年契約：現行機種から二年前の機種まで
3. 発売時に搭載されていた OS （そのまま使い続けている人）
4. 現在の最新OS環境（バグが少なく理想的な環境）
5. 古い機種／古いOSがそろえられない場合が多い
6. テストラボ（キャリア、専門企業が提供する機器借用環境）
232012年7月13日金曜日
多機種対応の範囲1. リファレンス機での 100% のテスト
2. それ以外の機種で必要な最低限のテスト（10～20%程度）
3. 対応機種と、対応外の機種を明確に設定
4. 一般リリース後に報告をもらう体制、不具合機種への対応策
5. ハードウェア固有の要素を重点的に
画面サイズ、カメラ機能、動画再生
ハードウェアキー、各種センサー、GPS位置情報
242012年7月13日金曜日
多機種対応の実際1. まっさらな状況から、インストール確認
2. 起動確認（ネットワークの有無に影響される場合もあり）
3. 画面サイズの違いによる表示のずれがないか？
4. 文字サイズの設定の違いによる表示のずれがないか？
5. 画面の色味の違いが無いか？（青っぽい？屋外での見え方）
6. 動作スピードの違い、アニメーション、滑らかな動きか？
252012年7月13日金曜日
多機種対応の作戦1. まずは開発者当人らが長時間いろいろな場面で使い込む
2. 多くの周りの関係者にベータテストユーザーになってもらう
3. 家族や知り合いなどにベータユーザーになってもらう
4. 一般ユーザーを募集して、初期試用してもらう
5. 初期リリース時、可能であれば、利用人数に制限を設ける
6. リリース時に大々的に宣伝・告知せず様子を見る。ある程度安定し、初期ユーザーが満足してからリリースでも遅くない
守秘義務前提
262012年7月13日金曜日
リリース後が本番1. リリース時にデバッグ用の何かが残っていないように
2. デバッグ用の何かを削除したために不具合がおきないように
3. バグゼロは難しい。既知のバグを把握した上でリリースする
4. 一般ユーザーからバグ報告を受ける時用にバージョン表記
5. メールやWebによるサポート体制（比較的小規模で良い）
6. スマートフォンアプリの利用者コミュニティーを構築する
7. 利用している外部APIのバージョンアップに目を光らせる
272012年7月13日金曜日
Tools&
Books
282012年7月13日金曜日
Android Design Previewhttp://code.google.com/p/android-ui-utils/
画面を転送実機確認
292012年7月13日金曜日
Adobe Shadowhttp://labs.adobe.com/technologies/shadow/
複数機種を一度に確認
302012年7月13日金曜日
iScreenhttp://www.drahtwerk.biz/EN/Home.aspx
画面を転送実機確認
312012年7月13日金曜日
リモートスマホレンタルhttp://www.katomakku.com/
遠隔地の実機を試用
322012年7月13日金曜日
Android 開発者メニュー
テストやデバッグの助けとなる各種機能
332012年7月13日金曜日
GORILLA LOGIChttp://www.gorillalogic.com/
iOS用。機能テストを自動化するツール。操作記録、再生、自動テスト用のスクリプト記述ができる。モンキーテストにも利用可。
342012年7月13日金曜日
TestFlight(iOS)https://testflightapp.com/
ベータ版のテストアプリを
多くのベータユーザーに平易に届け、的確なフィードバックを得られる仕組み
352012年7月13日金曜日
iPhoneアプリ設計の極意
思わずタップしたくなるアプリのデザイン
http://www.oreilly.co.jp/books/9784873115023/
362012年7月13日金曜日
Android Application Testing Guide
http://www.packtpub.com/android-application-testing-guide/book
372012年7月13日金曜日
ソフトウェアテスト293の鉄則
http://ec.nikkeibp.co.jp/item/books/P81540.html
382012年7月13日金曜日
Resources
392012年7月13日金曜日
公式資料を参照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
402012年7月13日金曜日
まとめ
実機テスト最重要すべてを疑う
あらゆる状況を想像
412012年7月13日金曜日
モバイルアプリの初期バージョンは必ず失敗する
User Experience 重要行動パターンの見極めシンプル／フォーカステーマ設定で意思統一膨大なデザイン修正
Dave Morin (Path CEO)
422012年7月13日金曜日
Q&A
432012年7月13日金曜日
452012年7月13日金曜日
462012年7月13日金曜日
それが革新的で無い限り標準にしたがうべきであるヤコブ・ニールセン
472012年7月13日金曜日
ルールは破ってもよいが無視してはならないティモシー・マサラ
482012年7月13日金曜日
Design Patterns（公式）http://developer.android.com/design/
492012年7月13日金曜日
Design Principles原理／原則／法則
502012年7月13日金曜日
驚くような方法で
512012年7月13日金曜日
リアルなオブジェクトで
522012年7月13日金曜日
自分のものに感じられる
532012年7月13日金曜日
教えてあげる
542012年7月13日金曜日
シンプルな文言で
552012年7月13日金曜日
文字より画像（印象）
562012年7月13日金曜日
決定はユーザーに
572012年7月13日金曜日
メニューは必要項目だけ
582012年7月13日金曜日
現在位置がわかるように
592012年7月13日金曜日
データは消して無くさない
602012年7月13日金曜日
同じように見えるものは同じ動きをする
612012年7月13日金曜日
余計な通知はしない中断させない
622012年7月13日金曜日
使い方を覚えるきっかけを
632012年7月13日金曜日
失敗した時は、なぜかではなく回避方法を
642012年7月13日金曜日
複雑な作業を小さなステップにステップごとに達成感を
652012年7月13日金曜日
エキスパートになったかのような気分に
662012年7月13日金曜日
重要なものは素早く使えるすべての操作が平等では無い
672012年7月13日金曜日
