Androidクローズドテスト審査で落ちた理由と、相互テストで解決した話

Androidアプリのリリース直前、クローズドテストを終えて申請したところ、普通に審査で落ちました。

コードや機能の問題ではなく、
テストの質に関する指摘でした。

最初は理由がよく分からず、かなり詰みました。
結果的に、相互テストという形で解決したので、その経緯を書きます。

審査で落ちたときの状況

当時の状況はこんな感じです。

• クローズドテストは実施済み
• テスターは数人いる
• 期間も一応確保した
• 重大なバグはなし

正直、
「これで通らない理由があるのか？」
と思っていました。

指摘されたポイント（推測含む）

Google Playから明確な数値基準は示されませんが、
状況を振り返ると、問題はここでした。

1. テストが“形式的”に見えていた

• 起動回数が少ない
• 利用パターンが単調
• 実際に触られている感が薄い

2. フィードバックがほぼ無かった

• クラッシュレポートなし
• コメントや改善要望なし

つまり
「本当にテストしているのか？」
という状態です。

個人開発の限界に気づいた

ここで痛感しました。

• 知り合いに頼むテストには限界がある
• 入れてもらっても、忙しくて触られない
• フィードバックを催促するのも気を使う

個人で完結させるのは、
現実的ではありませんでした。

試したが厳しかった方法

一時期、

• 複数アカウント
• エミュレータ
• 自分でテストを回す

という方法も考えました。

ただ、最近は

• エミュレータ由来の挙動が判別されやすい
• ネットワークや端末条件が厳しくなっている

などの理由で、
安定した方法とは言えなくなっています。

相互テストという選択

最終的に取ったのが、

• 同じ立場の開発者同士で
• お互いのアプリを実際に触る
• 最低限のフィードバックを返す

という相互テストの形でした。

これにより、

• 実端末での自然な利用ログ
• 起動回数・操作履歴の増加
• フィードバックの蓄積

が揃いました。

再申請の結果

同じ内容で再申請したところ、
今度は問題なく通過しました。

大きな修正をしたわけではありません。

変えたのは
「テストの成立のさせ方」だけです。

なぜ相互テストが効いたのか

振り返ると理由は明確です。

• 実在するユーザー
• 自然な操作
• 開発者視点のフィードバック

これらは、
一人で作ろうとしても限界があります。

実際にやっている取り組み

現在は、
Androidクローズドテストを相互に支援するコミュニティ
（ACTC）を運営しています。

• テスターが集まらない
• 審査理由が分からず詰む
• 形式だけのテストになってしまう

こういった問題を避けるための場です。

まとめ

審査で落ちた理由は、

• テストが実質的に成立していなかった
• 利用実績とフィードバックが弱かった

これに尽きます。

Androidクローズドテストは、
やったかどうかではなく
成立しているかどうかが見られます。

これから申請する人は、
テストの集め方を早めに考えておくと、本当に楽になります。