Androidアプリ開発・テストについて

個人レベル、中小企業レベルで、端末の互換性までテストしてアプリを開発しているところはごく少数かと思います。
特にAndroidは端末の種類が相当数ありますので、すべてを購入してテストということはかなり難しいかと思います。

基本的には、エミュレータを使い、実機はリファレンス端末を数機種決めて、それで動作テストや検収を行うところが多いかと思います。

予算が取れれば、こういったテストを専門に行っている業者がいくつかありますので、そういった企業に頼んでテストしたり端末を借りるなどしていますが、通常は、アプリ公開後何等か問題のある機種が判明したら、その機種を入手して修正・・・とういような感じの場合が多いと思います。

ケースバイケースですかね。
全ての機種で動作確認が必要か否か？の判断が必要だと思います。
B to Bの場合は、メーカーや機種を限定できる場合が多いですね。
B to Cの場合は、メジャーな機種を絞り込むのが多いです。

もちろん、検証機種を増やす場合は、価格・工数に比例して対応はしています。
予算が合うなら、処理対象にはします。

要は顧客の要件・要求が全てだと思います。

あくまで顧客が「全て」を求めるのであれば、それに応じた「価格・工数」を必要としますし！　それはどの業者に依頼らせても同じ結果になるでしょう。

要件に応じて絞り込みをされる事で最終的には顧客（発注者様）の予算が安く抑えられるわけですから、そこは最終的に顧客と相談して決めれば良い事だと思います。

これは余談ですが！　

自分の場合は、「メーカー・機種を限定できないAndroidと指定される」場合は、
「iPhone/iPadで開発するよりも見積額が高くなる」と言う旨を説明はする場合があります。

「ハードはApple社の製品の方が高額ですが、検証機種が多くなると開発費用はAndroidの方がはるかに高くなります。」
と言うような説明をする時もあります。

B to Cのケースでは難しい場合もありますが、B to Bの場合はこれで再検討していただけるケースもありましたし、Androidの場合は機種を制限していただけた場合もありました。

自分の場合は、Android開発の場合事前にお客様に確認を入れ「見積書・提案書」等に作業範囲の対応機種欄に対応機種を明確に明記して了承をいただきます。

また、検証機種が多い場合にはそれに応じた工数も当然ご提示いたします。

OSのバージョンに関しては、"例外もありますが"
対象機器の一番古いOSのバージョンにターゲットを合わせます。
それでも、動作しない場合はC/C++(NDK)なら#ifdefで使い分けたりしています。
JAVAやUnity(C#)の場合も、同様の対応ですかね。

あくまでこれは余談ですが！　

弊社ではメジャーな機種に絞ってデバッグしていますが、
検証工程を指定される案件では、リモートテストキットを使っていますよ。
https://appkitbox.com/testkit/

価格も安くオススメです。

> 妥協点として、利用者が多いAndorid端末・バージョンに絞って実機を用意し、
> テストを行うのが良いのだろうかと思っていますが、皆様はどのようにされているのでしょうか。

私の経験では、対象とする市場の何割程度のユーザを網羅するかという観点で範囲を定めていました。
例えば、AndroidバージョンであればAPILevel9以上であれば何割網羅できるとかです。
一方、端末に関しては利用者の多い端末の上位X機種で何割網羅できるという形です。

この判断をする上で重要になるのは対象とする市場のシェアのデータです。

Androidのバージョンに関しては、Googleからバージョン別のシェア情報が発信されておりAndroid Studio でプロジェクトを新規作成するときにウィザード上で確認できます。こちらを参考にして対象のAPIレベルを決定しています。
ただしこのシェア率は世界市場での値のため国内に限れば値は異なるので注意が必要です。

また、機種別のシェア情報に関しては有償で独自リサーチに基づいたデータを提供している企業等があるようですが、少なくとも一般公開されているようなデータはありません。自社のサービスで機種情報を収集できるのであれば、そのデータに基づいてシェアを判断するのが良いかと思います。

また機種に関してはメーカや搭載チップセットによって不具合の傾向が似てくるのである程度カテゴライズも可能です。

多くの端末、OSバージョンを網羅することは、非常に時間とコストがかかってしまいます。
Android搭載機器は、多種多様。一般のユーザでもPhoneタイプ、Tabletタイプを利用していますし、ディストリビュータ
毎に独自の仕様を入れ込んでいるものもあります。
それにOSのバージョンアップでセキュリティレベルも細かく変更されフットプリント情報も取得できるのが限定されています。
それなので、基本的な考えはリファレンスモデルを数機種選定して動作検証を実施し、その他の機種については、エミュレータを使用して検証してリリース。機種依存の不具合等については都度対応という方針でよいと思います。

依頼元からの要望にもよりますが、必要であれば外部検証サイトや委託も考慮しますが、やはりコストに見合わないケースが多いので割り切られたほうが良いと思います。

できるだけ多くの機種に対応できるように、修正を最小限に抑えることを考量すると、設計段階でできるだけ画面とロジック・制御部分を丁寧に分離して、モジュール化を考量されたほうがよいでしょう。

私どもは以下の方法で対応しています:

- エミュレータでのテストは行いますが、完全な実機環境とは限りません。

- ユーザ登録型テストサービス(ex. TestFlight)を利用し、多様な実機でのテストを依頼者サイドで行っていただいています。

- ベタテスターに実機を貸与し、レポートをもらうこともあります。

- 利用者が多い一部の端末(処 Android/iOS共にFlagshipモデル)に絞って保有しています。

個人開発では難しい分かりますが、依頼者サイドでユーザ登録型テストサービスを活用いただくことをおすすめしています。

実績と評価を積み上げれば、将来的には複数の実機を保有できると考えています。

以上がアドバイスとして参考になれば幸いです。ご検討いただければと思います。