遊軍的な立場で開発することが多いAndroid開発者です。
最新の技術よりは枯れた内容を相手にすることが多い中、培ってきた技術を共有します。

注意（という言い訳）

このページは 試験項目書に類するものがあること を前提として、
試験の前の手詰まりや後戻りを減らし、問題や気づきを得ることを目的としています。
……つまり曖昧な内容です。

サポートするOSの最小/最新で確認するとか、しきい値を中心に動かすとか、通信を切って動かすとか、入力項目があれば大量のコピペで埋めるとか、文字列にエスケープシーケンスを混ぜるとか、ボタンがあったら同時押しや連打するとか、解像度の低い端末でも確認するとか、クラッキング的な攻撃手法の検証とか、
具体的な項目を挙げて試験技術を向上させる方法は、このページにはありません。

それらの情報が必要な人は、
他のページを参照したり、日本スマートフォンセキュリティ協会さまが展開してくれている資料を読んだりしてください。

1. 開発者向けオプションの有効化

OSによってやや異なりますが、基本は設定画面の「デバイス情報」の「ビルド番号」欄を10回押すと有効化されます。
開発端末は既に有効化されていると思いますが、初期化されることも多いテスト専用の端末だと有効化されていないことがあります。
有効化しておくと後述するように色々と役に立ちます。

2. システム系アプリのアップデート

意外と重要です。
テストには初期化された端末や久しぶりに電源を入れた端末も使われます。
特に「AndroidシステムのWebView」あたりが古いと、WebViewが普段と違う動きをすることがあります。
実際にWebRTCを使うアプリを検証した際、有償で時間制限のある社外の検証センターで動かなくて焦りました。
気付くのが遅かったらヤバかったな……。

3. テスト用Googleアカウント

GoogleアカウントがなければGoogle Playを使えないので、上のシステム系アプリのアップデートもできません。
かといって、見ず知らずの端末に個人的なGoogleアカウントを設定したくないですよね。
開発用もしくはテスト用のGoogleアカウントを1つは持っておきましょう。
開発対象のサービスによってはメールアドレスを使うこともありますが、Gmailならエイリアスを作成することで1つのアカウントで複数に分けることもできますので管理もしやすいです。

4. リリースするときと同じビルドのapk/aabで確認すること

ついやってしまうのがデバッグビルドのバイナリで試験をすることです。
リリースビルドで難読化する場合に考慮が漏れているとあっさりクラッシュします。

「テストは開発末期で修正も多い中、わざわざapkやaabを書き出してそれぞれの端末に入れるなんて時間が取れないよ」という気持ちはわかりますし、
JSONをパースしたりDBを扱ったりする場所でなければ問題が起きた記憶はありませんが、
リリースビルドで難読化をするなら、テストの最初と最後だけでもリリースビルドのバイナリを使いましょう。
リリース直前にリリースビルドのapkを初めて動かしたらクラッシュした、なんて考えたくもないです。

5. 開発者向けオプション -> システムUIデモモード

下記のスクリーンショットを見てください。
なにか気づくことはありませんか？

~~サンプルアプリがひどすぎるのはさておき~~
時刻が10時ピッタリ、充電も100%になっています。
これはシステムUIデモモードとして表示しています。
ステータスバーの情報が固定されて余計な通知マークも表示されなくなるので、他の案件の通知が出ないようにエビデンスとしてスクリーンショットを取りたいときにオススメです。

6. 開発者向けオプション -> バグレポートのショートカット

この項目を有効化しておくと、電源メニュー内にバグレポートの出力が並びます。
すべてのクラッシュが再現性のあるものではないので、バグレポートをすぐに吐き出せると偶発的なクラッシュも調査しやすいです。

注意
バグレポートには、システムのさまざまなログファイルのデータが含まれており、他人に知られたくないデータ（アプリの使用状況、位置情報など）が含まれている場合もあります。バグレポートの共有は、信頼できる人やアプリとのみ行なってください。

7. 開発者向けオプション -> タップを表示

タップが可視化されます。
手順の伝達はテストにおいて重要ですが、タップが可視化できるなら動画で撮れば省くこともできます。

8. 開発者向けオプション -> レイアウト境界を表示

開発実装時に「〇〇のアプリと似た感じで作って」という要望を受けた際に他アプリを参考にする際に使うことが多いですが、デザイン重視の案件で余白を確認するときにも使うことがあります。
デバッグUIの痕跡も見えてしまうので、不要なUIはリリース前にGONEで消しておくか、お客さんに確認をしておきましょう。

9. 開発者向けオプション -> GPUオーバードローをデバッグ

2重3重に描画している箇所がわかります。
ハードウェア性能が向上して描画で詰まることは少なくなったので、この項目を見ることはあまりないかもしれません。
専用端末を使っている案件やAndroid TVなどスペックが低めの端末でパフォーマンスを求められたときに最後に使うくらいでしょうか。

10. 開発者向けオプション -> 厳格モードを有効にする

厳格モードとはStrictModeのことです。

こちらも開発者向けの項目ですが、UIスレッドでストレージの読み書きなど重い処理を走らせていると赤く点滅するようになるので潜在的なANRの予防くらいにはなります。

11. Android Studio -> Logcat

Android端末をPCに繋げて、Android Studioを見ながら動作確認することも大事です。
クラッシュ時の情報収集が主ですが、リリースビルドなのにヤバいログは流れてませんか？
いつの頃からかスクリーンショットや録画もできるようになっており、エビデンスの強化にもバッチリ使えます。

12. Android Studio -> Attach Debugger to Android Process

デバッガです。
デバッガを使わず実装時に想定した条件で確認するのが1番ですが、本筋とは関係ない場所で必要以上に時間を割かないようにするのは良いことですよね。
ブレークポイントで止めて流れを確認したり、値を書き換えて別の分岐に通したり、1行ずつ実行することでクラッシュする箇所を探ったり、試験の効率化に大いに関係があリます。

13. Android Studio -> Profiler

ProfilerではCPU使用率とメモリ使用量を見ることができます。
バグの修正時にこそよく使いますが、

バックグラウンドで動く処理がないにも関わらず何らかの処理が動いている
画面を開いて戻るを繰り返すとメモリ使用量がどんどんと増えていく

など、問題の兆候に気づくこともあります。

AndroidのOSによって実行できるものが異なるので煩雑な印象はありますが、CPU処理に関するTraceやメモリのheap dumpで詳細を知ることが有効です。
「Java/Kotlin Method Trace」では時間がかかっている処理を特定しやすく、
heap dumpではメモリリーク箇所が確認できます。
こういう有効だけど煩雑な場所にこそスクリーンショットを用意して説明すべきですが、サンプルアプリ程度だと大したものが出なくて説明できなかったので割愛しました……。

14. Android Studio -> Running Devices

PCに繋いでいるAndroid端末実機をミラーリングして操作できます。
PCから手を離さずにテストを継続できるのも便利ですが、それ以上にPCのキーボードを使ってAndroid端末に入力できるのが良いです。
スマートフォンで長文を打ちたくない、ですよね……？
（若い子は違うそうです）

15. Android Studio -> App Inspection

こちらはデータベースやネットワークの調査に特化しています。
アプリ内DBを扱う案件ではここを見て実際のデータ型を確認しておきましょう。
ネットワークは設定が必要なのでCharlesなどを使ったほうが楽な印象です。

16. Android Studio -> Build Variants

環境を切り分けるときに使う機能です。
テストとは少し違いますけど、普段は動かしたくない環境があるなら注意して名前を付けましょう。
リポジトリからソースを取り込んだ直後のような初期状態ではアルファベット順で1番若いものが選択されますので、うっかり動かしても問題ない構成が望ましいです。
product/test ではなく develop/product みたいな。

17. adb モンキーテスト

$ adb shell monkey -p your.package.name -v 500

空き時間にモンキーテストもかけておきます？　めったに役に立ちませんのでダメで元々。

終わりに

ここまで、あーだこーだと書いてきました。
「お前はいつもこんなことやってきたのか。その割にはクオリティが――」と思う方もいらっしゃると思います。
そう、私も普段から全部やれているわけではありません！
……ご迷惑をかけている方にはお詫び申し上げます、本当に。

思うに、試験で物を言うのは、このページには書いてない開発体制と試験項目の出来、試験までにかけられる時間です。
仕様を責任者から開発者や試験担当者に齟齬なく理解できる形で伝達できていて、
普段からコードレビューを行なっているようなら試験は難しくないでしょう。

しかし、現実には時間も費用も人員も有限なのでできる範囲で折り合わなきゃいけません。
せめて、テストの本筋とは関係ないところで詰まらないように、テストが早く終えられるように、問題があるなら早く見つかるように、と紹介してきました。
小手先ではありますが、これを読んだ方が少しでも得るものがあれば幸いです。

以上！

余談

そうそう、重要なことを忘れてました。
Androidアプリのテストに限りませんが、PCスペックが思っていた以上に大事でした。

スペックが影響する仕事として最たるものはビルドで、
転職前の旧PC(2016年8GB)では初回ビルドに10分かかっていた案件が、
転職後の新PC(2023年32GB)で1分でビルドが終わったのは驚きました

今まで当たり前のように並列でのほほんと作業してましたが、ここまで差が出てしまうと作業方法を変える必要がありましたね……。
もし集中して作業ができないなら道具を変えてみると良いかもしれません。