Android受け入れテストガイドライン

ガイドライン作成へのアプローチ – その2

日本Androidの会テスト部

Shigeta IKUJI

​

2012.3.24

*

© 2011 ACCESS CO., LTD. All rights reserved. | Confidential

• Androidアプリのテスト全般について
• 情報共有
• 情報発信
• @IT連載開始！
• オープンプロダクトコミュニティにおける

​

「ぶっちぎりのテスト力」

​

をテスト部から世界へ

https://sites.google.com/site/androidtestclub/

Androidテスト部(ATEC)ご紹介

The Power of One Billion

本日の御品書

​

• なぜ、Android受け入れテストガイドラインが必要か
• 受け入れテストに求められている問題

​

• 本日までのあらすじの紹介
• ユーザー意見をガイドライン化すればいいんじゃあないか？

​

• Android開発とはサービス開発だ！
• リリース後の端末サポートも含めてAndroid開発です

​

• 「Android開発サービス」のためのガイドライン例
• サービスという視点から見ると見えてくる新しい項目

*

The Power of One Billion

我々は何に困っているか

• 動かない！

​

• 売れない！

​

Androidアプリを作ったはいいが。。。

儲からない！

*

The Power of One Billion

ソフトウェアテスト標準用語集（日本語版）

• 受け入れテストの定義は…
• 「システムが、ユーザのニーズ、要件、ビジネス・プロセスを満足するかをチェックするための公式のテスト。このテストにより、システムが承認基準を満たしているかを判定したり、ユーザ、顧客、その他の認可主体がシステムを承認するかしないかを判定したりできる。」
• とされているが…

今、現場の「受け入れテスト」に求められている事とは

�どこでも動くこと と たくさん売れること

*

The Power of One Billion

動かない！売れない！

キャリア

メーカー

D

K

S

SH

N

P

OS 2.1

キャリア

メーカー

D

K

S

SH

N

P

OS 2.2

キャリア

メーカー

D

K

S

SH

N

P

OS 2.3

*

「差別化」という商売の原則と「標準化」という理想

根本解決には、膨大な実機テストをするしか方法がない

低単価という現実へのニッチorグローバル戦略

マーケティングであり画一的なガイドライン化は難しい

​

The Power of One Billion

Android受け入れテストガイドラインへのアプローチ

• 前提1:求められている「受け入れテスト」とは�「動く＆売れる」ためのテストである
• 動くもの
• 動くモノのためのテストは、膨大な他機種テストによる以外難しい
• 売れるもの
• 売れるモノのためのテストは、マーケティングプロセスであり一意なガイドライン化は難しい

​

• 前提2：Androidとはそういうものだ
• OSベースの変化・低アプリ単価・非”Run Anywhere”
• ガイドラインは後方互換と横展開を主目的とするべき
• 割り切りが必要で、品質保証コストがかけられない
• ガイドラインは完璧なものを追い求めるべきではない

​

この前提でどのようにガイドラインを導出するか

*

The Power of One Billion

本日までのあらすじ

The Power of One Billion

ユーザーフィードバックによるガイドライン最適化の提案

• そもそもガイドラインとは？
• ガイドラインはことわざのようなものだと考える

​

• ガイドラインを守ると良いことがある
• ガイドラインを守るとより動く＆より売れる
• ガイドラインは何かを保証するものではない

よって

• ガイドラインは経験則であり知恵（Wisdom）である
• Practice といってもいいかもしれない

​

ユーザ意見の集合から

ガイドライン（知恵）を導出できないだろうか？

*

前回のあらすじ

The Power of One Billion

実例紹介

※企業の実データ部分は会場のみの公開になります

ごめんなさいm(_ _)m

​

The Power of One Billion

Information

to

Knowledge

*

The Power of One Billion

内容種別から情報を知識化

• 意見 ：市場要求の獲得
• どんなユーザーがどんなことを求めているか
• 必要な機能、不要な機能等の情報を知識化

​

• 質問 ：市場認識の獲得
• 質問の発生原因は先方と当方間の認識不一致
• 準不具合としてUIやドキュメントへの反映により情報を知識化

​

• 不具合 ：品質評価の獲得
• 手元で試験し切れなかった障害情報の獲得
• 対応ユースケースの増加により情報を知識化

​

原文の実例をいくつか紹介

*

The Power of One Billion

意見

• デザインは良いんだが動きがもっさりして気に食わなかった。

​

• 戻るキーでバックする際、ブラウザバック先がない場合残っているタブ?を開く又は他のタブ?が参照できるといいですね～

​

• Why there is no addressbar in the browser. You must add address bar in the browser,

​

• 標準ブラウザに比べて、どうしても一番下にコントロールバーがあるので画面が狭くなってしまう＾～～～＾；；なので半透明にする等工夫がいるのでは？＾～～～＾？

*

The Power of One Billion

質問

• ○○ で切り抜いた画像ってどこに保管されるん？(´・ω・`)

​

• 画像又はテキストのみ表示させるSimple Browsingのような機能は搭載されてますか？

​

• 全画面表示にはならないんですかね？

​

• みているページのURLを表示したりコピーするにはどうしたらいいですか?

​

• 標準ブラウザからブックマークを取り込む手段はありませんか？

*

The Power of One Billion

不具合

• How can this browser manage not to work on stock 2.2 on the G2?

​

• Force close to Samsung Galaxy S Vibrant 

​

• Doesnot work on my device...htc aria for att unlocked

​

• After install, says its not compatible with my device. Samsung intercept

​

• The phone's name is OPTIMUS ONE�I really wanna use your App.....

*

The Power of One Billion

Knowledge

to

Wisdom

*

The Power of One Billion

知識（解決ノウハウ）から�ガイドラインという形で抽象化する

• 市場要求 ：例えば非機能要件のガイドライン
• 特定の端末ユーザから集中して”遅い”という意見が出たとする
• クレーム端末と非クレーム端末の中間に規定すべき値がある

​

• 市場認識 ：例えばUIポリシーのガイドライン
• ある機能について使い方が分からず質問が集中したとする
• その機能かUIには何か問題があり他の部分には問題がない

​

• 品質評価 ：例えばコーディング規約のガイドライン
• リセットや機能不全を解析すると特定の原因にたどり着く
• 回避方法や根本修整方法をガイドラインとして纏めていく

*

The Power of One Billion

前回のまとめ

• ガイドラインが”Wisdom”であるなら”Data”から帰納できる
• あるアプリに対する有象無象の意見や評価（Data）
• XXが使いにくい！という意見
• Dataを整理分析した結果（Information）
• 「XXが使いにくい！」という人の統計化
• Informationから作成した有用な解決法（Knowledge）
• 「XXが使いにくい！」という人の求める「○○のような」UI/UXの実現方法
• Knowledgeから導き出された経験的な法則（Wisdom）
• 「○○のような」UI/UXのポリシーをガイドライン化

​

Android受け入れテストガイドラインは

ユーザーフィードバックの分析から獲得できる！

*

The Power of One Billion

今回の

提案

The Power of One Billion

前回の結論の問題点

• ユーザーフィードバックから導出する方法の問題点
• 1^st Releaseに対しては割り切りが必要
• Marketで一度低評価を受けると二度と浮かびあがれないリスク
• アプリ毎に行うため俯瞰的なガイドラインまで遠い
• 得られた知見がノウハウ直結のため共有が困難

​

• 求められているものは
• 初期リリース時にも効果的でありたい
• Androidアプリ全体を対象としたい
• 企業間の競争領域を避けて共有したい

​

ユーザーフィードバックは非常に有用だが

出荷前に受発注間で共有できる仕組みが欲しい

*

The Power of One Billion

【再考】Android受け入れ試験の難しさ

• iアプリ：キャリア買取制度の強み
• メーカーを巻き込んで、アプリプラットフォームの差分を抑制
• キャリア課金の整備による統一ビジネスプラットフォームの提供
• iOS：単一メーカーによる単一ブランドの強み
• 同じ製品間では、そもそもアプリ実行環境の差分が少ない
• それでも端末差分で泣きを見ることも…
• iTunesで作り上げた世界標準ビジネスプラットフォームの提供
• Windows：Wintelといわれた統一ソリューション販売の強み
• PC/AT標準規格を最大限活用したアプリ実行環境の統一
• 高単価物理パッケージの流通ビジネスプラットフォームを保有

​

Androidは「自由の代償」として

プラットフォーム環境の一意性が弱い

*

The Power of One Billion

Android開発で考慮するサービス/サポート要素

Android Application

国や地域別の法律

画面サイズ、CPU、RAM、�独自センサー

Version別

提供機能、API

オペレータ別

レギュレーション、

通信QoS

自前クラウド連携

SaaS SLA要件

3^rd パーティ

連携CSP

レギュレーション

SLAなどで対応

現在論じている部分

俎上に無いが要検討

*

俎上に無いが要検討

The Power of One Billion

Androidのプラットフォーム環境

• Androidはプラットフォームの制約が緩い
• 実行環境の考慮はアプリ側が多機種試験で対応
• 実行環境の変更はアプリ側が都度リリース運用で対応
• ビジネス環境の考慮はアプリ側が関係者と調整
• ビジネス環境の変更はアプリ側が規約を監視して対応

​

⇒システム開発における運用と同様に環境の追従対応は不可避

⇒特定プラットフォーム向けアプリ開発というより�比較的広い対応範囲のカスタムメイドシステム開発

​

現実としてAndroid開発とは、

プラットフォーム変化の追従対応運用（サポート）を伴う

「サービス開発」ではないだろうか？

*

The Power of One Billion

サービス開発のサポート範囲規定方法

• SLA（Service Level Agreement）
• 提供者と顧客で契約を行う際に、サービスの内容、範囲、品質水準を明確にし、達成できなかった場合のルールを含めて合意する契約
• 既存のSLAガイドライン
• SaaS向けSLAガイドライン
• 2008年1月21日　経済産業省
• 民間向けITシステムのSLAガイドライン
• 2008年1月31日　電子情報技術産業協会
• クラウドサービスレベルのチェックリスト
• 2010年8月16日　経済産業省

​

Android開発がサービスならば受入れテストには

サポート/運用契約（SLA）を考慮する必要がある！

*

The Power of One Billion

「Android受け入れテスト」に求められること

顧客に売るため

端末で動くため

過去

未来

試験対象端末の

割り切りをした上での

「ユーザ受け入れテスト」

×

顧客は常に未来にいる

市場調査や

ユーザフィードバックを

反映するための

「フィールドテスト」

将来起こりうる

リスクに対してSLAによる

「運用受入れテスト」

各テストの項目は、ユーザフィールドバックにより継続更新

これらを組み合わせることで

最終的な”顧客満足”を実現

*

The Power of One Billion

Android SLA ガイドラインの作り方

• まずはとっかかりが必要
• 既存のベストプラクティス（Wisdom）を集める
• ベストプラクティスの理由を分析する
• 解決方法のパラメータ（Knowledge）を項目化
• これがSLAガイドラインの雛形になるのでは

​

• 既存のベストプラクティスとは…？
• App Store Review Guidelines
• Windows Phoneアプリケーション認定の要件

を参考にできるんじゃないだろうか

*

The Power of One Billion

具体的なSLA項目の作成実験

• App Store Review Guidelines
• 2.1 クラッシュするアプリはリジェクトされる
• 2.15 20MB以上のアプリは移動機通信網ではダウンロードできない
• 2.17 アプリのBrowser機能はiOS webkit framework と webkit JS を使わなければならない
• 2.22 地域やキャリアによってアプリ使用の制限をしてはならない
• 10.5 ボリュームや呼び出し音のスイッチなど標準スイッチ機能の変更はリジェクトされる
• Windows Phoneのアプリケーション認定の要件
• 4.1.1 XAP パッケージ ファイルの最大サイズは 225 MB です。
• 4.4 アプリケーションは、Windows Phone Marketplace のサポートされるアプリケーション言語の 1 つ以上の言語でローカライズする必要があります。
• 5.1.3 アプリケーションが、デバイスが 3 秒よりも長く応答していないように見える原因となる操作 を実行する場合、アプリケーションは視覚的な進行状況またはビジー インジケーターを表示する必要があります。
• 5.2.1 アプリケーションは、起動後、5 秒以内に最初の画面を描画する必要があります。
• 5.2.5 アプリケーションで RAM の使用量が 90 MB を超えてはなりません。ただし、256 MB を超えるメモリが搭載されたデバイスは例外です。

​

*

The Power of One Billion

Android SLA ガイドライン項目標本

*

The Power of One Billion

まとめ

The Power of One Billion

今回のまとめ

• ユーザーフィードバックの分析結果は企業ノウハウ直結のため、業界間の共有が難しい
• Androidの弱点は、自由の代償としてP/Fの一意性が相対的に弱いこと
• P/F変更追従が不可避なのであれば、そのサポートは�「サービス」として認識するべきではないか

​

• サポート範囲はSLAとして受発注間で認識/合意するのが現実的なのではないか？

​

• このSLA項目が有効ならば、企業の競争領域ではないのだから業界で育てて業界で広く共有しよう！

The Power of One Billion

「受け入れテストガイドライン」の今後の活動予定

• 引き続き、各種レギュレーションなどから項目化
• 世のガイドラインや企業ヒアリングなどから項目作成

​

• 皆さんのAndroid開発トラブル体験を募集！！
• 入力フォーム（匿名可）：http://bit.ly/GLt0Uw
• 要求仕様外の事項で顧客検証NGを食らった例
• ユーザーから予想外のクレームを受けた例
• 想定外の損害賠償に発展しかけた例

​

• SLA項目化して公開＆共有します！！
• オープンなコミュニティだからできることを
• 受発注間共通のコミュニケーションツールに
• 業界全体で提案依頼（RFP）や要求仕様定義の精度向上を目指します！

*

以上、ありがとうございました�m(_ _)m

The Power of One Billion