smartphone test (know how & tools)

Post on 13-Nov-2014

770 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

 

TRANSCRIPT

これだけはやっておきたいスマートフォンを成功に導くテストの極意

多機種対応の勘所や品質向上効果の高いツール活用のヒント

株式会社エクサ/ユビキタスPCMソリューション部

安藤幸央

2012.7.13 14:35~15:15

@yukio_andoh yukio-ando@exa-corp.co.jpall 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日金曜日

Thank you !

yukio-ando@exa-corp.co.jp

442012年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日金曜日

top related