Закрите тестування Google Play: 12 тестувальників, 14 днів і план, що дає доступ до production (2026)

Якщо ваш акаунт розробника Google Play — нещодавно створений особистий акаунт, закрите тестування Google Play є бар'єром, який треба пройти до запуску. На момент подання заявки на production щонайменше 12 тестувальників мають бути підписані на ваш закритий тест, і кожен має бути підписаний безперервно протягом попередніх 14 днів. Ставтеся до цього як до двотижневого тестового проєкту з відповідальною особою, графіком і циклом зворотного зв'язку, а не як до галочки, яку ставлять в останній день.

Що вимагає закрите тестування Google Play у 2026 році?

Станом на листопад 2026 року особисті акаунти розробників, створені після 13 листопада 2023 року, мають провести закритий тест із «щонайменше 12 тестувальниками, які були підписані безперервно щонайменше 14 днів», перш ніж зможуть подати заявку на доступ до production. Доти опції Production і Pre-registration для застосунку залишаються заблокованими.

• 12 тестувальників мають бути підписані на закритий тест у момент подання заявки.
• Вони мають бути підписані протягом попередніх 14 днів, безперервно.
• Тестувальник, який відписався й підписався знову, має знову набрати 14 днів поспіль, щоб його врахували.
• Закрите тестування стає доступним після завершення налаштування застосунку. Відкрите тестування залишається заблокованим, доки ви не отримаєте доступ до production.
• Внутрішнє тестування не має передумов, але це окремий трек.

Правила наведено на сторінці Google App testing requirements for new personal developer accounts. Ця сторінка стосується лише особистих акаунтів. Про акаунти організацій там нічого не сказано, тож перевірте, що показує ваша власна Dashboard, а не робіть припущень у той чи інший бік.

Як налаштувати трек закритого тестування в Play Console?

Щоб налаштувати закритий тест, відкрийте в Play Console Test and release > Testing > Closed testing, натисніть Manage track, додайте тестувальників на вкладці Testers і розгорніть реліз. Тестувальників можна додати списком email-адрес або через Google Group. Кожен список вміщує до 2 000 користувачів, тож розмір списку ніколи не є обмеженням. Обмеження — це змусити людей підписатися.

1. На вкладці Testers створіть список email-адрес або вкажіть Google Group, наприклад yourgroupname@googlegroups.com.
2. Додайте URL або email-адресу для відгуків. Google показує їх на сторінці підписки для тестувальників.
3. Скопіюйте посилання для підписки та збережіть зміни.
4. Створіть реліз на закритому треку й розгорніть його.
5. Коли реліз опубліковано, надішліть посилання для підписки разом з URL у Play Store. Тестувальники не зможуть знайти застосунок до production через пошук у Play.

На сторінці налаштування тестів Google перелічує кілька пасток. «Посилання для підписки відображається лише тоді, коли статус застосунку — 'Published'», тож у застосунків у статусі Draft і Pending publication посилання немає. Завантаження CSV перезаписує адреси, які вже є у списку, а файли CSV, збережені як UTF-8 з BOM, відхиляються. У випадку з Google Group люди мають спершу приєднатися до групи, а вже потім підписатися. Кожен, хто вже бере участь у вашому внутрішньому тесті, має вийти з нього, перш ніж зможе отримати закритий тест.

Скільки тестувальників залучати і хто з них зараховується?

Залучайте 15–16 тестувальників, а не 12, бо зараховуються лише ті, хто підписався через посилання Play, а той, хто вибуває до 14-го дня, не зараховується взагалі. 14 днів кожного тестувальника починаються з моменту його підписки, тож той, хто приєднався пізно, відсуває найранішу дату подання заявки.

Хороші джерела — ваша розсилка, список очікування бети, друзі з Android-телефонами та інші інді-розробники, які протестують ваш застосунок, якщо ви протестуєте їхній. Попросіть кожного підтвердити, що він прийняв посилання для підписки й установив застосунок із Play. APK, встановлений вручну, або пересланий білд не зараховуються. Якщо ваш застосунок платний, Google зазначає, що тестувальники мають купити його, щоб взяти участь, — це ще одна причина запропонувати безкоштовний тестовий білд або промокоди.

Що мають робити тестувальники протягом 14 днів?

Тестувальники мають користуватися застосунком так, як це робили б реальні користувачі, отримуючи конкретне завдання кожні кілька днів, щоб ви збирали відгуки й випускали виправлення ще під час тестового періоду. Форма заявки на production питає, чи тестувальники використали всі функції та чи відповідало їхнє використання реальній поведінці, і вам потрібні відповіді на обидва питання.

Тестувальники не можуть залишати публічні відгуки на тестові версії. Збирайте відгуки через ваш URL чи email для зворотного зв'язку або через приватні відгуки в Google Play. Ведіть журнал: кожен звіт, що ви змінили і який білд це виправив. Якщо тестування виявляє аварійні завершення чи зламані екрани, план тестування релізного білда для відхилень за 2.1 стане корисним чеклистом і для Android-білдів.

Що відбувається, коли розробники отримують «потрібно більше тестування»?

Публічні звіти показують: досягнення потрібної кількості тестувальників дає змогу подати заявку, але не гарантує схвалення. Схвалення від відмов відрізняють помітна залученість тестувальників та оновлення, зроблені на основі відгуків.

• Відмова після сервісу тестувальників. У спільноті MIT App Inventor розробник у липні 2024 року (коли поріг становив 20 тестувальників) повідомив, що набрав потрібну кількість через сервіс обміну тестувальниками. Попри це він отримав лист «More testing required to access Google Play production» з причинами «Тестувальники не взаємодіяли з вашим застосунком під час закритого тесту» та «Ви не дотрималися найкращих практик тестування, які можуть включати збір відгуків користувачів і реагування на них». Google написав йому: «Перш ніж подавати заявку знову, протестуйте застосунок у закритому тестуванні ще 14 днів із реальними тестувальниками». Він також зазначив, що не зміг заповнити форму після тесту, бо не знав, хто його тестувальники і як вони тестували. На сторінці обговорення не повідомляється про вирішення.
• Схвалення після переробленого тесту. Розробниця на DEV Community з'ясувала, що більшість друзів і родичів користуються iPhone. Застосунок установили лише 4–5 людей, і приблизно половина видалила його за кілька днів. Вона перейшла на Google Group із налаштуванням «Anyone can join» і залучила інших розробників через застосунок для взаємного тестування, який рекламується в дописі. За два дні вона набрала 14 тестувальників, випустила 6 невеликих оновлень за тестовий період і ретельно заповнила форму. Вона повідомляє про схвалення через два дні після подання заявки.

Висновок: обидва розробники досягли потрібної кількості тестувальників. Схвалений міг показати реальне використання, оновлення та відгуки, а відхилений мав лише цифри без доказів, які можна описати у формі. Якщо ви вже отримали такий лист, посібник про «More testing required» у Google Play пояснює, що змінити перед повторною заявкою.

Про що питає форма Apply for production?

Форма Apply for production, яку відкривають із Dashboard, має три частини: ваш закритий тест, ваш застосунок і ваша готовність до production. Відповіді втрачаються, якщо натиснути Discard або вийти з розділу, не натиснувши Next, тож підготуйте їх заздалегідь.

Google також попереджає, що «перевірка — це не етап усунення несправностей». Перед поданням заявки переконайтеся у відповідності правилам, наявності вікового рейтингу, стабільності та, якщо застосунок вимагає входу, робочих облікових даних. Посібник із налаштування демо-акаунта написано для Apple, але той самий вхід для рецензента підходить і для Google.

Що перевірити, перш ніж натиснути Apply for production?

Перед поданням заявки переконайтеся, що щонайменше 12 підписаних тестувальників мають по 14 днів поспіль, що журнал відгуків показує випущені виправлення і що всі завдання з налаштування застосунку виконано. Плануйте дату запуску з урахуванням перевірки Google, яка «зазвичай триває сім днів або менше, але іноді може тривати довше».

Практичний приклад: соло-розробник завершує налаштування застосунку в понеділок і розгортає білд 1. Він запрошує 16 людей зі списку очікування та спільноти розробників, і до 2-го дня підписуються 14. Він нагадує двом людям і додає ще трьох. На 4-й день тестувальник повідомляє про аварійне завершення на старішому пристрої, і на 5-й день виходить білд 2. Оскільки ті, хто приєднався пізніше, почали свої 14 днів пізніше, розробник рахує дні для кожної людини окремо, а не від першого релізу. Він подає заявку, коли 12 людей мають по 14 днів поспіль, із журналом, де зафіксовано дев'ять знайдених багів і сім виправлених.

1. Dashboard показує щонайменше 12 підписаних тестувальників, кожен із яких має 14 днів поспіль.
2. Останній білд на закритому треку — саме той, який ви плануєте просунути, і він відповідає поточному цільовому рівню API (див. посібник про цільовий рівень API 36).
3. Журнал відгуків містить знайдені проблеми, внесені зміни та випущені білди.
4. Сторінку в магазині, віковий рейтинг, розділ безпеки даних та інші завдання налаштування завершено.
5. Облікові дані для входу рецензента працюють, якщо застосунок вимагає входу.
6. Відповіді для форми підготовлено, і вони конкретно описують реальних тестувальників і реальні зміни.

Якщо ви також випускаєте застосунок на iOS, чеклист для публікації в App Store охоплює бік Apple. Якщо ви волієте передати запуск іншим, наш сервіс публікації в App Store налаштовує Play Console і App Store Connect та готує обидві перевірки за $599; збори за акаунти розробника оплачуються окремо. Також можна написати на yagyeshsrbobde@gmail.com.