smartphone test (know how & tools)

771 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
771
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

smartphone test (know how & tools)

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

×