Share via

パート 6 - テストと App Store の承認

  • [アーティクル]

テスト

多くのアプリ (一部のストアでは Android アプリでさえも) は、公開前に承認プロセスに合格する必要があります。そのため、テストは、アプリを確実に市場に投入するために (ましてや顧客との間で成功を築くために)、非常に重要です。 テストは、開発者レベルの単体テストから、さまざまなハードウェアにわたるベータ テストの管理まで、さまざまな形式を取ることができます。

すべてのプラットフォームでテストする

.NET が Windows Phone、タブレット、デスクトップ デバイスでサポートする内容には若干の違いがあり、また、iOS には動的コードをその場で生成できないようにする制限があります。 開発時に複数のプラットフォームでコードのテストを計画するか、プロジェクトの最後にアプリケーションのモデル部分をリファクタリングして更新するための時間をスケジュールします。

シミュレーター/エミュレーターを使用して、複数のバージョンのオペレーティング システムと、さまざまなデバイスの機能/構成をテストすることを常にお勧めします。

また、可能な限り多くの異なる物理ハードウェア デバイスをテストする必要もあります。

クラウド内のデバイス

携帯電話とタブレットのエコシステムは常に成長しており、増え続けている利用可能なデバイス上でテストを行うことが不可能になっています。 この問題を解決するために、多くのサービスでは、多数の異なるデバイスをリモートで制御する機能を提供し、多くのハードウェアに直接投資しなくてもアプリケーションをインストールしてテストできるようにしています。

App Center テストは、数百の異なるデバイスで iOS および Android アプリケーションを簡単にテストする方法を提供します。 詳細については、「Xamarin.Android Apps の準備」および「Xamarin.iOS アプリの準備」を参照してください。

テスト管理

組織内でアプリケーションをテストするか、外部ユーザーと共にベータ プログラムを管理する場合、次の 2 つの課題があります。

  • 配布 – プロビジョニング プロセスを管理し (特に iOS デバイスの場合)、更新されたバージョンのソフトウェアをテスト担当者に提供します。
  • フィードバック – アプリケーションの使用状況に関する情報と、発生する可能性のあるあらゆるエラーに関する詳細情報を収集します。

これらの課題に対処するために、使用状況とエラーを収集して報告するためのアプリケーションに組み込まれたインフラストラクチャを提供し、プロビジョニング プロセスを合理化してテスト担当者とそのデバイスのサインアップと管理を支援することで、多くの役立つサービスを利用できます。

Visual Studio App Center には、これらの課題に対するソリューションが用意されており、テスト バージョンの配布、クラッシュ レポート、高度なアプリケーション使用状況情報が提供されます。

テストの自動化

Xamarin UITest を使用して、自動化されたユーザー インターフェイス テスト スクリプトを作成できます。これらは、ローカルで実行したり、App Center テストにアップロードしたりできます。

単体テスト

Touch.Unit

Xamarin.iOS には、JUnit/NUnit スタイルに従ってテストを記述する Touch.Unit という単体テスト フレームワークが含まれています。

テストの記述と Touch.Unit の実行の詳細については、Xamarin.iOS での単体テストに関するドキュメントを参照してください。

Andr.Unit

Android 用の Touch.Unit に相当するオープンソースの Andr.Unit があります。 これは github からダウンロードすることができ、@spouliot のブログでこのツールについて紹介しています。

App Store の承認

Apple と Microsoft は、それぞれ App Store と Marketplace というプラットフォーム上で唯一のストアを運営しています。 どちらもデバイスをロックダウンし、ダウンロード可能なアプリケーションの品質を制御するための厳格なアプリ レビュー プロセスを実装しています。 Android のオープンな性質は、広く利用可能でレビュー プロセスがない Google Play から、Amazon Appstore for Android や、より限定的な配布を実施し、承認プロセスを実装する Samsung Apps などのハードウェア固有の取り組みまで、多くのストア オプションがあることを意味します。

アプリのレビューを待つことは非常にストレスになることがあります。ビジネス上のプレッシャーにより、"目標の" 発売日より前に、エラーの余裕がほとんどない状態でアプリケーションが承認のために送信されることがよくあります。 プロセス自体に最大 2 週間かかる可能性があり、必ずしも透明性が高いとは言えません。最終的に拒否または承認されるまでは、アプリケーションの進行状況に関するフィードバックは限定的です。 拒否は、特にそれが複数回発生し、元の発売日からアプリが最終的に承認されるまでに数週間が経過している場合、マーケティングの好機を逃すことを意味する場合があります。

準備する

最初のアドバイス: アプリのローンチは十分余裕を持って計画し、拒否や再送信の可能性を考慮に入れてください。 各ストアでは、アプリを送信する前にアカウントを作成する必要があります。可能な限り早くこれを行います。 アプリが無料の場合、Google Play のサインアップには数分しかかかりませんが、それらを販売していて、銀行や税金の情報を提供する必要がある場合は、プロセスにより多くの作業が関与します。 Apple と Microsoft のプロセスはどちらも Google よりもはるかに複雑です。アカウントが承認されるまでに 1 週間以上かかる可能性があるため、この時間をローンチ計画に織り込んでください。

アカウントが承認されたら、アプリを送信する準備が整います。 アプリを送信する実際のプロセスについては、次のドキュメントを参照してください。

このセクションの残りの部分では、アプリが問題なく承認されるようにするために考慮すべき事項について説明します。

Quality

当たり前のことのようですが、一定レベルの品質を満たしていないためにアプリケーションが却下されることはよくあります。そもそも、キュレーション ストアが承認プロセスを設けているのはこのためです。

拒否の一般的な理由はクラッシュです。 アプリがあまりにも簡単にクラッシュする場合、確実に拒否されます。 ほとんどの開発者は、クラッシュすることを想定してアプリを送信しませんが、アプリはよくクラッシュします。 アプリを送信する前に十分にテストします。その際、すべてが機能することを確認するだけでなく、ネットワークの問題やメモリやストレージ領域といったリソースの制約など、一般的なモバイル エラー シナリオに確実に対処することにも重点を置いてください。 シミュレーターと物理デバイスの両方を使用してテストします。シミュレーターでのコードの実行がどれだけうまくいっても、アプリの実際のパフォーマンスを示すことができるのはデバイスだけです。 できるだけ多くの異なるデバイスを使用し、可能であればベータ テスターのチームに参加します。サードパーティのサービスは、ベータ版の配布とフィードバックの管理に役立ちます。

すべてのモバイル オペレーティング システムは、十分に速い速度で起動しないアプリケーションを中止します。 許容される時間の長さはさまざまですが、一般的に、アプリは数秒で応答することを目指し、長時間がかかる作業を行う場合は、バックグラウンド タスクを使用します。 読み込みに時間がかかりすぎるアプリや、通常の使用で十分な応答性がないアプリは拒否されます。 バックグラウンドで何かが発生している場合は、常にユーザー フィードバックを提供してください。そうしないと、アプリがクラッシュしているように見え、もう一度拒否されてしまいます。

エッジ ケースを確認する

開発者によくある罠は、エッジケース、特に適切にテストするためにシミュレーターやデバイスの再構成が必要なケースに対処できないことです。 すべての顧客が自分の位置情報へのアクセスをアプリに "許可" するわけではないことを簡単に忘れてしまいます。これは、開発者が一度要求を受け入れると、再びプロンプトが表示されることはないためです。 承認プロセスでは、アクセス許可とネットワークの使用が特に重視されるため、これらの領域で小さな見落としがあると拒否される可能性があります。

次の一覧は、見落とされた可能性があるエッジ ケースをチェックするための適切な出発点です。

  • 顧客はサービスへのアクセスを "拒否" できます – 特に iOS では、ジオロケーション情報などのデータへのアクセスは、ユーザーがアプリケーションにアクセス許可を付与した場合にのみ提供されます。 アプリケーションのテスト担当者は、アプリケーションを初期状態で頻繁に再インストールし、いかなるアクセス許可要求も許可しないようにして、アプリケーションが適切に動作するようにする必要があります。 アクセス許可のオンとオフを切り替えて、顧客の考えの変化に合わせた正しい動作を確認します。
  • 顧客はあらゆる場所に存在します – アプリはそれが開発された都市や国でのみ使用されると想定しないでください。 GPS 座標、日付と時刻の値、および通貨を処理するコードはすべて、顧客の位置情報とロケールの設定の影響を受ける可能性があります。 すべてのプラットフォームには、異なる場所とロケールを指定できるシミュレーターが用意されています。これを使用して、他の半球や、日付や通貨の形式が異なる文化圏の場所でテストを行います。 緯度と経度の値は正または負の値にすることができ、小数点の区切り記号にはピリオドまたはコンマを使用でき、日付はさまざまな方法で書式設定できます。
  • 低速ネットワーク接続 – アプリ開発者は、多くの場合、高速で常に動作するネットワーク接続という「理想的な世界」で仕事をしていますが、現実の世界では明らかにそうではありません。 低速のネットワーク接続 (低品質の 3G 接続など) を使用したテストや、ネットワーク アクセスがない状態でのテストは、バグのあるアプリを出荷しないようにするためにきわめて重要です。 承認プロセスには、必ず機内モードのデバイスを使用したテストが含まれるので、自分がそのテストを行ったことを確認してください。
  • ハードウェアはさまざまです – サポートする予定の最も古く、最も遅いハードウェアでテストすることを忘れないでください。 アプリに影響を与える可能性がある 2 つの側面があります。1 つはパフォーマンスです。古いデバイスでは使用できない可能性があります。もう 1 つは、カメラ、マイク、GPS、ジャイロスコープ、その他のオプション コンポーネントなどのハードウェア機能のサポートです。 コンポーネントが使用できない場合、アプリケーションは適切に低下する (クラッシュしない) 必要があります。

ガイドラインは単なる「ガイド」以上のものです

Apple は、そのプラットフォームの重要な強みの 1 つが一貫性 （および認識されたユーザビリティの向上） であるため、ヒューマン インターフェース ガイドラインの遵守に厳しいことで有名です。 Microsoft は、Fluent Design System を実装する Windows アプリケーションについて同様のアプローチを採用しています。 両方のプラットフォームの承認プロセスでは、関連する設計理念にアプリが準拠しているかどうかが評価されます。

ユーザー インターフェイスのイノベーションがサポートされていないとか推奨されていないと言うのではなく、"やってはいけない" ことがいくつかあります。そうしないと、アプリが拒否されます。

iOS では、これには組み込みのアイコンを誤って使用したり、他のよく確立されたメタファーを一貫性のない方法で使用したりすることが含まれます。たとえば、[compose] (作成) アイコンを新しいコンテンツの作成以外の操作に使用することなどです。

Windows 開発者も同様に注意する必要があります。よくある間違いは、Microsoft のガイドラインに従ってハードウェアの [戻る] ボタンを適切にサポートできないことです。

設計者に各プラットフォームの設計ガイドラインを読んで従うように促してください。

プラットフォーム固有の機能の実装

プラットフォーム固有のサービスの実装 (特に iOS の場合) に関しては、処理が少し厳しくなります。 Apple による自動拒否を回避するために、次の iOS 機能には従うべき規則がいくつかあります。

  • アプリ内購入 - アプリケーションは、ゲーム内通貨、アプリケーション機能、雑誌のサブスクリプションなど、デジタル製品の外部支払いメカニズムを実装してはなりません。 iOS アプリでは、この種の機能に Apple の iTunes ベースのサービスを使用する必要があります。 抜け穴があります。Kindle Reader や一部のサブスクリプション ベース アプリなどのアプリでは、"アカウント" にアタッチされたコンテンツを他の場所で購入し、その後アプリ経由でアクセスできます。ただしこの場合、アプリにはアプリ外での購入プロセスへのリンクや参照を含めてはなりません (そうでないと、アプリがまた拒否されます)。
  • iCloud のバックアップ - iCloud の出現により、Apple のレビュー担当者は、アプリがストレージを使用する方法に関してより一層厳しくなりました (顧客のリモート バックアップ エクスペリエンスが快適であることを保証するため)。 バックアップ可能なストレージ領域を無駄にするアプリは拒否される可能性があるため、キャッシュ フォルダーを適切に使用し、Apple の他のストレージ関連のガイドラインに従ってください。
  • Newsstand - 新聞や雑誌のアプリは Apple の Newsstand に最適ですが、アプリが承認されるには、少なくとも 1 つの自動更新サブスクリプションを実装し、バックグラウンド ダウンロードをサポートする必要があります。
  • マップ - モバイル マップにオーバーレイやその他の機能を追加することはますます一般的になっていますが、マップの "クレジット" 情報 (iOS5 の Google ロゴなど) を隠さないように注意してください。隠されていると、拒否されるためです。

メタデータの管理

アプリケーションが拒否される可能性がある明らかな技術的な問題に加えて、特に App Store または Marketplace 内に表示するためにアプリケーションと共に送信するメタデータ (説明、キーワード、マーケティング画像) に関して、拒否される可能性があるアプリの送信に関するより繊細ないくつかの側面があります。

  • 画像 – アプリケーションのアイコンとストア画像に関するプラットフォームのガイドラインに従ってください。 商標化された画像を使用しないでください。アプリのアイコンに iPhone の描画が含まれていたため、アプリが拒否されたのを見たことがあります。
  • 商標 – 自社以外の商標は使用しないでください。. Apple の App Store では、アプリの説明やキーワードに商標を記載したために、アプリが拒否されました。
  • 説明 – "ベータ版" という単語を使用しないでください。また、どのような方法であれ、アプリがプライム タイム (最も良い状態) になっていないことを示さないようにしてください。 (アプリがクロスプラットフォームの場合でも) 他のモバイル プラットフォームについて言及しないでください。 最も重要なのは、そのアプリが、あなたが指示することを正確に実行するようにすることです。 説明に多数の機能を一覧表示する場合は、それらの各機能の使用方法を明確にすることをお勧めします。そうしないと、"アプリケーションの説明に記載されている機能が実装されていません" という拒否を受けることになります。

アプリケーションのメタデータには、開発やテストと同じくらいの労力をかけてください。 メタデータの軽微な違反でアプリケーションは拒否されるため、時間がかかっても正しい状態にする価値があります。

App Store: 全員が対象ではない

各プラットフォームのストアの主な焦点は、コンシューマー向けの配布、つまり可能な限り多くの顧客にリーチする能力です。 ただし、すべてのアプリケーションがコンシューマーを対象としているわけではなく、従業員、サプライヤー、または顧客に限定した配布を必要とする社内およびエクストラネットのようなアプリケーションのベースが急速に増加しています。 これらのアプリは "販売対象" ではなく、承認は必要ありません。開発者がクローズドなユーザー グループへの配布を制御するためです。 この種類のデプロイのサポートは、プラットフォームによって異なります。

Android は、この件に関して最も柔軟性が高く、アプリケーションは URL や電子メールの添付ファイルから直接インストールできます (デバイスの構成で許可されている限り)。 つまり、社内の企業向けアプリケーションを作成して配布したり、特定の顧客やサプライヤーにアプリケーションを公開したりすることは簡単です。

Apple は、iOS Developer Enterprise Program に登録されている開発者に社内展開オプションを提供しています。これにより、App Store の承認プロセスをバイパスして、企業が社内アプリを従業員に配布することができます。 残念ながら、このライセンスは、顧客やサプライヤーの他のクローズド グループに対するエクストラネットのようなアプリ配布の必要性に対応していません。 エンタープライズ (およびアドホック) 展開

App Store のまとめ

レビュー プロセスは困難な場合がありますが、開発ライフサイクルの残りの部分と同様に、計画を立てて、詳細に注意することで成功を収めることができます。 これはすべて、単純ないくつかの手順で完了します。従う必要があるユーザー インターフェイスのガイドラインを読んで理解し、プラットフォーム固有の機能を実装する場合はルールに従い、十分にテストし (その後さらにテストする)、最後にアプリケーション メタデータが正しいことを確認してから送信します。

Google Play で公開する開発者への最後のアドバイス: 承認プロセスがないことは、仕事を簡単にするように見えるかもしれません。しかし、顧客の要求はレビュー チームよりもさらに厳しくなります。 アプリが拒否される可能性があると思って、これらのガイドラインに従ってください。そうしないと、あなたの顧客が拒否を行います。