トップAndroidデベロッパーはこうしてアプリの品質テストを行っている

次の記事

ETSIがApple提案の超小型SIMカードを正式に規格化, 互換性は完全


数週間前、私は香港のデベロッパーAnimocaが同社のAndroidアプリをどうやってテストしているかに関する記事を書いた。アプリのダウンロード数7000万を超える会社で、どのアプリについても400種類のデバイスでテストしている。上の写真は同社の本社を写したもので彼らが使っているAndroidの携帯電話とタブレットのほんの一端を示している。

いうもでもなく記事は多くのAndroidサポーターの怒りを買った。記事が将来のデベロッパーを怖じ気づかせると指摘するコメントもあった。Androidの分裂や何百というデバイス、画面サイズ、解像度、OSバージョンをサポートしなければなからないという認識に怯えるのではというのである。

そこで私は、他のモバイルゲーム開発者がどうやってAndroidの品質管理をしているかを聞いてみた。これがその結果だ。

Red Robot LabsBenchmark Capitalが出資。EA、Playdom、およびCrowdstar出身のベテラン創立チーム。ダウンロード数3500万以上。現在Google Playストア売り上げ第27位のアプリを保有している)

Red Robotは社内に約12台のデバイスを持ち、品質保証チームは2名からなる。他に英国拠点のTestologyという会社に依頼してさらに35機種をカバーしている。

「私は共通感覚というフィルターを利用している」と共同ファウンダーのPete Hawleyは言う。彼はEA出身でゲーム業界で15年の経験を持つ。同氏は80/20ルールに沿ってユーザーの大半をカバーする少数の機種を識別する。まずGoogleが公表しているAndroidの異なるバージョンおよび画面サイズ、解像度毎の出荷台数を見る。次に同社のゲームユーザーがどの機種をよく使っているかを分析する。最後にプレーヤーからの要望とsupport ticketを見る。

サポートするデバイスを厳選するのはいい方法だと彼は言う。特にアジア方面からさまざまなローエンド端末が来る状況下では。

「小さくて貧弱な旧機種や古いOSにノーと言うことも大切」と彼は言う。「全体的にみてすべての端末、キャリアー、OSに対応することは、思っていたほど大変ではなかった。80%を丁寧にカバーすることはたいした話ではない」。

これは昨年秋のRed Robotのデバイス分布だ(非常に分裂したパイである)。



Pocket Gems:
(Sequoia CapitalRedpoint Venturesが出資。7000万ダウンロード以上。Androidでは比較的新参だが、昨年のiOSゲーム売上トップ10に2本入っている。Google Playでは売上35位)

Pocket Gemの品質保証テストは元米国空軍大佐Ray Vizzoneが率いている。彼らは40台強のデバイスを使い下のビデオで説明されているようなマトリックスに沿って評価している。タブレットとスマートフォンの両方が含まれ、次に高解像度と低解像度機種が含まれているよう確認している。さらに、主要グラフィックチップ(GPU)5種、Adreno、PowerVR、Tegra、Mali、およびVivanteを網羅するようにしている。

同社の品質保証プロセスは超高速になるようデザインされている。これはゲーム業界がここ数年根本的に変ってきているからだ。Zyngaがソーシャルゲーム業界でやってきたのと同じように、こんにちのモバイルゲームは店で手に取るような完成品というよりサービスに近い。そのため数日ごとに新鮮なコンテンツによるアップデートを続ける必要がある。

サンフランシスコ拠点の同社にとって、品質保証テストは一週間7日24時間体制で、米国内および海外のチームが関わる。米国チームが昼間テストを設計し実施した後、同じ40機種のAndroid機を揃えた海外チームに引き渡す。このチームがさらに徹夜で互換性テストを行い見つけたバグを問題追跡システムに入力すると、それが翌朝米国チームに渡る。

Pocket Gemは全機能を3つのフェーズに分けてテストする。1)新機能テスト、2)統合テスト、3)出荷候補テスト。開発チームがゲームの新機能を開発している間にもQAチームはデザインテストの準備を進めているので出来次第すぐに確認できる。機能が安定したらゲームに統合され次のテストに入る。

「統合テスト中にバグが見つかり修正されると製品マネージャーとテスト責任者がリスク評価を行い、出荷に向けていつコードを凍結するかを判断する」と共同ファウンダーのHarlan Crystalは説明する。「この判断が下されると、全体回帰テストが開始される」。

この最終工程にはメモリー、性能、デバイス互換のテスト一式が含まれる。「この工程で致命的なバグが見つからなければ、神に祈って出荷する」と彼は言う。

Pocket Gems Android QA Process

Storm8: (3億ダウンロード以上。自己資金のみで設立。Androidの売上トップにゲームが3つ。ファウンダーらはFacebookの初期メンバー。)

Storm8は30から50のデバイスを使用し、ハイエンド、中間、ローエンドに分けている。意識的にカテゴリーのデバイスを購入している。ゲームを公開した後、彼らのアプリからはさまざまなKPI(Key Performance Indicators:重要性能指標)が同社のサーバーに送られてくる。

「こうすることによって、特定の種類のデバイス、さらには特定機種向けに微調整が必要かどうかがわかり、デバイスの極限まで性能を追求できる。」とCEOのPerry Tamは語る。

Animoca(7000万ダウンロード以上。IDG-AccelおよびIntel Capitalが出資)。

最初の記事掲載後、Animocaは長い記事を書いてなぜこれほど多くのデバイスで品質保証テストが必要かを説明した。主たる理由は、同社は中国本土およびアジア各地に膨大なユーザーを抱えており、そこにはローエンドや非互換Android機(同じOSを使ってはいるがGoogleアプリが動作することが公式Android App storeで認定されていない)大量にあるからだという。

「もしわれわれが90%互換で十分というアプローチをとれば、700万ダウンロードをサポートできなくなる」と同社は説明する。「われわれの決断によって数百万人が悪い体験をし、アプリの売上が10%は落ちるだろう」。

Animocaは決して若い会社ではないことに注意されたい。この会社はOutblazeというデジタルメディアを10年以上扱っている会社のモバイルゲーム専門の子会社である。このため互換性と品質保証テストに関しては豊富な経験を持っている。

同社CEOのYat Siuは、同社がこのプラットフォームで良い実績をあげている理由の一つは「包括性」だと言う。Animocaは現在米国の売上トップ50に入るゲームを持っていないが、アジア市場での人気と年間に公開するアプリの数によってそれを補っている。

結論:これでもまだ恐れをなすというなら、フィーチャーフォンの時代はもっと悲惨だったことを思い出してほしい(少なくともRoviaのPeter Vesterbackaはそう言っている。彼曰くJ2ME/Brewの時代と比べるとAndroidはむしろ楽だ!彼らは超ヒット作のAngry Birdsを作るまでに50以上のゲームを作らなくてはならなかった)。

当時どれほど苦労していたかの参考のために、JAMDATが2005年のIPOの際に使ったスライドを下に貼ってある。JAMDATはフィーチャーフォン時代の代表的モバイルゲーム買収劇の主役で、Electronic Artsに6.8億ドルで買われた。同社は5年をかけて40カ国以上の90以上のキャリアーと関係を築き、400機種をサポートすることは当たり前だった。

というわけでAndroidの断片化は頭痛の種に思えるかも知れないが、みんなのパパのモバイルアプリ会社は、雪の中7マイルの坂道を登る400機種のQAテストを行い、100社のキャリアーの人々とビジネスを築いてきたのである。

また、Red Robotが利用しているTestologyやuTestなど、モバイルのQAテストを専門に行う会社を利用するのも簡単な方法だ。それでも、最大級のデベロッパーはやはり殆どすべてを社内でやりたいのだろう。

[原文へ]

(翻訳:Nob Takahashi)

“トップAndroidデベロッパーはこうしてアプリの品質テストを行っている” への3件のフィードバック

  1. たるー より:

    日本のケータイアプリもこんな感じでやってそう。
    提携40カ国の中に日本も入ってるんだろうなぁ、やっぱり。

    • ゲスト より:

      ガラケー時代は3キャリア(ドコモAUソフトバンク)対応が基本でした。
      同キャリアの端末なら互換性は保証されているので、基本そのキャリアの最低スペックの端末(多くの場合発売が5年前位の端末)で検証して動作すればほとんど問題はありませんでした。ドコモとソフトバンクはJavaなので片方への移植は比較的簡単でしたが、AUだけはBrewという全く独自の環境だったので移植がとても面倒でした。

      ドコモはどの端末も高性能で開発も楽でしたが機種によってサウンドフォーマットが異なっていて同じサウンドを5タイプ作り直していましたね。アプリの公開方法の自由度が高くデバックが容易でした。
      ソフトバンク端末は互換性には優れていましたが全体的スペックが低かったです。
      AUのBrewはとても開発が面倒でした。

    • ゲスト より:

      ガラケー時代は3キャリア(ドコモAUソフトバンク)対応が基本でした。
      同キャリアの端末なら互換性は保証されているので、基本そのキャリアの最低スペックの端末(多くの場合発売が5年前位の端末)で検証して動作すればほとんど問題はありませんでした。ドコモとソフトバンクはJavaなので片方への移植は比較的簡単でしたが、AUだけはBrewという全く独自の環境だったので移植がとても面倒でした。

      ドコモはどの端末も高性能で開発も楽でしたが機種によってサウンドフォーマットが異なっていて同じサウンドを5タイプ作り直していましたね。アプリの公開方法の自由度が高くデバックが容易でした。
      ソフトバンク端末は互換性には優れていましたが全体的スペックが低かったです。
      AUのBrewはとても開発が面倒でした。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

フォロー

新しい投稿をメールで受信しましょう。

現在380人フォロワーがいます。