Чек-лист тестирования мобильного приложения перед релизом

За 2024 год Apple проверила 7 771 599 отправок в App Store и отклонила 1 931 400 из них — почти каждую четвёртую. Главная причина — категория Performance: 1 235 471 отклонение, то есть краши, недоделанные экраны и нерабочий демо-доступ (данные App Store Transparency Report 2024). Требования к «завершённости» приложения прямо прописаны в пункте 2.1 App Review Guidelines, а Google Play после релиза следит за стабильностью через Android vitals и может снизить видимость приложения, если оно часто падает.

Поэтому чек-лист тестирования мобильного приложения перед релизом полезнее собирать не одним длинным списком, а по фазам: что проверить за две недели, что — в день code freeze, что — перед кнопкой «Отправить на ревью» и что — в первые 72 часа после выхода. Так проверки не сваливаются на последний вечер, а у каждого пункта есть владелец и срок. Если релиз сдаёт подрядчик, проверьте, что в договоре на тестирование ПО есть регресс на реальных устройствах и прописаны критерии приёмки сборки.

Ниже — фазы подготовки, проверки по блокам (установка, функциональность, сеть, производительность, безопасность, совместимость, сторы), требования Google Play и App Store на 2026 год и сводный шаблон «Да / Нет / Блокер». Материал рассчитан на продакт-менеджеров, руководителей проектов, QA-лидов и заказчиков, которые принимают решение о выпуске. Если нужен разбор самих видов тестирования — функционального, регрессионного, нагрузочного и других, — он есть в статье «Виды тестирования мобильных приложений»; здесь мы на нём не останавливаемся.

Что такое релизный чек-лист и чем он отличается от тест-плана

Релизный чек-лист — это короткий список проверок и условий, по которому команда принимает решение go/no-go: можно ли выпускать конкретную сборку в сторы. Он не описывает, как тестировать, а фиксирует, что уже проверено и с каким результатом. Подписывают его обычно QA-лид и владелец продукта; при работе с подрядчиком — ещё и представитель заказчика.

Тест-план отвечает на вопрос «что и как мы тестируем в этом проекте», тест-кейсы — «какие шаги выполнить и какой результат ожидать». Релизный чек-лист стоит над ними и отвечает на вопрос «готовы ли мы к выпуску». Если в нём есть хотя бы один пункт со статусом «Блокер», релиз переносится.

Документ	Назначение	Кто ведёт	Когда	Результат
Тест-план	Стратегия: объём, виды тестирования, окружения, риски	QA-лид	В начале проекта или крупного релиза	Согласованный подход к тестированию
Тест-кейсы	Пошаговые сценарии с ожидаемым результатом	QA-инженеры	По ходу разработки функций	Пройденные или проваленные проверки, баг-репорты
Релизный чек-лист	Решение go/no-go по конкретной сборке	QA-лид и продакт	От code freeze до первых дней после релиза	«Выпускаем» или «переносим» с записанными рисками

Когда начинать: фазы подготовки к релизу

Подготовка к релизу мобильного приложения — это пять фаз, от заморозки объёма до мониторинга после выхода. Начинать стоит примерно за две недели до планируемой даты: точный срок зависит от объёма изменений, но сжатие этих фаз в два-три дня почти всегда означает пропущенный регресс. Ниже — типовой таймлайн, где T-0 — день выпуска.

1. T-14: заморозка объёма и план регресса. Зафиксируйте, какие задачи входят в релиз, а какие переносятся. Составьте план регресса по критичным сценариям, соберите парк устройств и проверьте доступы к тестовым окружениям.
2. T-7: code freeze и сборка-кандидат. Новые функции больше не принимаются — только исправления багов. Соберите release candidate с боевыми настройками, прогоните smoke-тест и полный регресс на реальных устройствах.
3. T-3: отправка на ревью. Загрузите финальную сборку, метаданные, скриншоты и демо-аккаунт в App Store Connect и Google Play Console. Закладывайте время на App Review и возможную повторную отправку.
4. T-0: поэтапный выпуск. Включите staged rollout в Google Play и phased release в App Store, начиная с небольшой доли аудитории. Держите наготове feature flags и серверный kill-switch.
5. T+72 часа: мониторинг и решение о расширении. Следите за крашами, ANR, отзывами, ошибками API и конверсией ключевых сценариев. Расширяйте выпуск, только если метрики в норме; при проблемах — останавливайте раскатку и готовьте hotfix.

Как проверить установку, обновление и первый запуск

Проверка установки и первого запуска — это проверка того, что пользователь вообще доберётся до продукта: приложение ставится, открывается и не теряет данные при обновлении. Эту часть часто пропускают, потому что разработчики годами работают с уже установленной сборкой. Минимальный набор:

• ☐ Чистая установка из тестового трека (TestFlight, внутреннее тестирование Google Play) на устройство, где приложения никогда не было.
• ☐ Обновление поверх предыдущей версии из стора: данные пользователя, настройки и локальная база мигрируют без потерь.
• ☐ После обновления сохраняется сессия — пользователя не выбрасывает на экран входа без причины.
• ☐ Обновление через одну-две версии (пользователь долго не обновлялся) — миграции применяются по цепочке.
• ☐ Удаление и повторная установка: приложение корректно стартует с нуля, без «хвостов» старых данных.
• ☐ Онбординг проходится до конца, его можно пропустить, и он не показывается повторно без причины.
• ☐ Запросы разрешений (уведомления, камера, геолокация) появляются в момент, когда они нужны, а не все сразу на первом экране.
• ☐ Работа на минимальной поддерживаемой версии ОС, заявленной в сторе.
• ☐ Холодный старт без сети: приложение показывает понятное состояние, а не белый экран.
• ☐ Размер сборки и объём загрузки после установки соответствуют ожиданиям — без случайно вшитых тестовых ресурсов.

Функциональность: критичные пользовательские сценарии

Функциональная проверка перед релизом — это smoke-тест и регресс сценариев, без которых приложение теряет смысл: регистрация, вход, основное действие и оплата. Проверять всё подряд за три дня до выпуска невозможно, поэтому критичные сценарии выделяют заранее и прогоняют их на каждой сборке-кандидате.

• ☐ Регистрация, вход, выход, восстановление пароля, вход через сторонние сервисы (если есть).
• ☐ Основной пользовательский путь: поиск, карточка, корзина или целевое действие — от начала до конца.
• ☐ Профиль: изменение данных, загрузка аватара, смена настроек.
• ☐ Удаление аккаунта из приложения работает и действительно удаляет данные на сервере.
• ☐ Негативные сценарии: неверный пароль, пустые поля, слишком длинный ввод, повторное нажатие кнопки.
• ☐ Deeplink, universal links и app links открывают нужный экран — и в запущенном, и в закрытом приложении.
• ☐ Push-уведомления доставляются, тап ведёт на правильный экран, а отказ от разрешения не ломает приложение.
• ☐ Формы и валидация: маски телефона и e-mail, понятные сообщения об ошибках, корректная работа клавиатуры.
• ☐ События аналитики по ключевым действиям отправляются с правильными параметрами.
• ☐ Исправленные в этом релизе баги проверены повторно, соседние функции — регрессом.
• ☐ Тексты, ошибки и пустые состояния согласованы с продактом — без заглушек «Lorem ipsum» и тестовых данных.

Платежи и встроенные покупки

Платёжный сценарий — самый дорогой по цене ошибки, поэтому его проверяют отдельно и на боевой конфигурации платёжного провайдера в тестовом режиме.

• ☐ Оплата банковской картой и через СБП: успешный платёж, отказ банка, отмена пользователем.
• ☐ Обрыв сети во время оплаты: нет двойного списания, статус заказа восстанавливается после повторного входа.
• ☐ Встроенные покупки и подписки работают и видны ревьюеру — Apple требует этого в пункте 2.1(b).
• ☐ Восстановление покупок на новом устройстве.
• ☐ Возврат и отмена подписки отражаются в приложении.
• ☐ Чек и подтверждение оплаты приходят пользователю.

Как приложение ведёт себя в реальных условиях: сеть, прерывания, фон

Проверка в реальных условиях — это тестирование того, как приложение переживает всё, что происходит с телефоном вне его контроля: плохую сеть, звонки, сворачивание и нехватку памяти. На стенде с быстрым Wi-Fi такие дефекты не видны, а в метро и лифте их встречают первыми.

• ☐ Медленная сеть (эмуляция 3G), потеря сети посреди запроса, офлайн-режим.
• ☐ Переключение Wi-Fi ↔ мобильная сеть во время загрузки или отправки данных.
• ☐ Входящий звонок, SMS, будильник и push от другого приложения во время ключевого сценария.
• ☐ Блокировка экрана и возврат в приложение — введённые данные не теряются.
• ☐ Сворачивание на несколько минут и возврат: экран и состояние восстанавливаются.
• ☐ Система выгрузила процесс из памяти — приложение поднимается без краша и без потери черновиков.
• ☐ Режим «Не беспокоить», энергосбережение и ограничения фоновой работы.
• ☐ Поворот экрана и смена темы во время работы (если поддерживаются).
• ☐ Камера, микрофон, геолокация: сценарий с разрешением и без него, повторный запрос через настройки.
• ☐ Смена даты, времени и часового пояса на устройстве не ломает таймеры, расписания и кеш.
• ☐ Заполненная память устройства: приложение сообщает об ошибке, а не падает.

Производительность и стабильность: какие цифры считать проходными

Производительность и стабильность перед релизом — это проверка скорости запуска, плавности интерфейса, расхода памяти и батареи, а также доли пользователей, у которых приложение падает или зависает. Для Android у Google есть публичные пороги «плохого поведения», для iOS таких публичных цифр нет — там ориентиром служат собственные данные о крашах.

• ☐ Холодный и тёплый старт сравнимы с предыдущей версией или быстрее.
• ☐ Прокрутка длинных списков и анимации без заметных подтормаживаний на бюджетном устройстве.
• ☐ Нет утечек памяти при многократном открытии и закрытии экранов.
• ☐ Расход батареи и нагрев при типичной сессии не выросли по сравнению с прошлым релизом.
• ☐ Размер сборки не вырос без объяснимой причины.
• ☐ Изображения и медиа кешируются и не скачиваются заново при каждом открытии экрана.
• ☐ Сбор крашей (Crashlytics или аналог) подключён и проверен тестовым крашем до выпуска.

Google Play оценивает стабильность по скользящему окну в 28 дней. Если приложение превышает пороги, магазин может снизить его видимость и показать пользователям предупреждение на странице приложения.

Метрика Android vitals	Порог в среднем по всем устройствам	Порог на одну модель телефона
User-perceived crash rate (заметные пользователю краши)	1,09%	8%
User-perceived ANR rate (зависания «приложение не отвечает»)	0,47%	8%
Окно оценки	28 дней; при превышении — снижение видимости и предупреждение в сторе

Для iOS аналогичных публичных порогов Apple не публикует: ориентируйтесь на краш-репорты в Xcode Organizer и в вашей системе сбора крашей и сравнивайте с прошлыми версиями. Если после релиза ожидается рекламная кампания и всплеск трафика, проверьте не только приложение, но и сервер: нагрузочное тестирование бэкенда стоит провести до маркетингового запуска, а не после первых жалоб.

Безопасность и персональные данные

Проверка безопасности перед релизом — это поиск того, что не должно попасть в продакшен: секретов в сборке, отладочных режимов, незащищённых данных пользователя. Плюс юридическая часть: согласие на обработку персональных данных и политика конфиденциальности, без которых ревью не пройти.

• ☐ Токены и пароли хранятся в Keychain (iOS) и Keystore (Android), а не в открытых настройках.
• ☐ В сборке нет API-ключей, тестовых эндпоинтов и паролей от служебных сервисов.
• ☐ Логи не содержат персональных данных, токенов и номеров карт.
• ☐ Debug-режим, меню разработчика и тестовые флаги выключены в релизной сборке.
• ☐ Весь сетевой обмен идёт по HTTPS; certificate pinning — если этого требует модель угроз.
• ☐ Код обфусцирован там, где это предусмотрено проектом.
• ☐ Согласие на обработку персональных данных запрашивается до сбора данных; хранение и обработка соответствуют 152-ФЗ.
• ☐ Ссылка на политику конфиденциальности есть и в карточке стора, и внутри приложения — этого требует пункт 5.1.1(i) правил Apple.
• ☐ Удаление аккаунта доступно из приложения.
• ☐ Сторонние SDK проверены: какие данные они собирают, отражено в политике конфиденциальности и в Data safety.
• ☐ Сессия корректно истекает, а после выхода данные пользователя недоступны.

Совместимость: на каких устройствах проверять

Проверка совместимости — это прогон критичных сценариев на наборе устройств и версий ОС, который отражает реальную аудиторию приложения. Источник для матрицы — ваша аналитика: какие модели, версии ОС и размеры экранов чаще всего встречаются у пользователей. Для Android матрица шире из-за фрагментации: разные производители, оболочки и ограничения фоновой работы.

• ☐ Топ моделей из аналитики своей аудитории плюс минимальная и последняя поддерживаемые версии ОС.
• ☐ Маленький экран, большой экран, планшет и складной телефон (если поддерживаются).
• ☐ Вырезы экрана, жестовая навигация и системные панели не перекрывают кнопки и поля ввода.
• ☐ Тёмная тема и крупный системный шрифт — вёрстка не ломается, текст не обрезается.
• ☐ Доступность: VoiceOver и TalkBack читают кнопки и поля осмысленно.
• ☐ Локализация: длинные строки, форматы дат, валют и телефонных номеров.

Эмуляторы и симуляторы удобны для быстрых проверок вёрстки и логики, но не заменяют реальные устройства: производительность, камера, push, работа в фоне и прерывания ведут себя на железе иначе. Если выделенного QA нет, начать можно с базового набора — в статье о том, как проверить приложение самостоятельно, мы разбирали минимальный порядок действий.

Платформа	Минимальный парк устройств	Зачем
Android	Бюджетный смартфон с небольшим объёмом памяти	Производительность, выгрузка процесса системой
Android	Устройство среднего сегмента с популярной у аудитории оболочкой	Ограничения фона, push, особенности производителя
Android	Флагман на последней версии Android	Новые системные требования и разрешения
iOS	iPhone на старейшей поддерживаемой версии iOS	Совместимость API и вёрстки
iOS	iPhone на актуальной версии iOS	Новые системные диалоги и поведение
iPadOS	iPad — если приложение его поддерживает	Адаптивная вёрстка, многозадачность

Что проверить перед отправкой в App Store и Google Play

Предрелизная проверка для сторов — это сверка сборки, метаданных и аккаунта разработчика с актуальными правилами магазинов. Ошибки здесь не ломают приложение, но откладывают выпуск на дни: сборку отклоняют на ревью или не пускают в production.

Требования Google Play в 2026 году

• ☐ Target API level: с 31 августа 2026 года новые приложения и обновления должны таргетировать Android 16 (API 36); для Wear OS и Android Automotive — API 35, для TV и XR — API 34. Продление можно запросить до 1 ноября 2026 года (требования Google Play к target API).
• ☐ Существующие приложения с target ниже API 35 не показываются новым пользователям на новых версиях Android — обновление target SDK нельзя откладывать.
• ☐ Сборка загружается в формате Android App Bundle (AAB) и подписана через Play App Signing.
• ☐ Раздел Data safety заполнен и совпадает с тем, какие данные приложение реально собирает.
• ☐ Для личных аккаунтов разработчика, созданных после 13 ноября 2023 года, пройдено закрытое тестирование: не менее 12 тестировщиков непрерывно 14 дней, только после этого можно запросить доступ к production (справка Play Console). Аккаунты организаций от этого требования освобождены.
• ☐ Сборка последовательно прошла треки: внутреннее тестирование → закрытое → открытое (при необходимости) → production.

Требования App Store

• ☐ Отправляется финальная версия: без плейсхолдеров, пустых экранов и «скоро будет» — пункт 2.1 App Completeness.
• ☐ Приложение протестировано на реальном устройстве и не падает: сборки с крашами отклоняются.
• ☐ Если есть вход — в App Store Connect указан рабочий демо-аккаунт, а бэкенд включён на всё время ревью.
• ☐ В Review Notes объяснены неочевидные функции, нестандартные сценарии и способ получить полный доступ.
• ☐ Ссылка на политику конфиденциальности указана в App Store Connect и доступна внутри приложения.
• ☐ Скриншоты, описание и возрастной рейтинг соответствуют реальному функционалу.
• ☐ Сборка прошла прогон в TestFlight на внутренних или внешних тестировщиках.

RuStore и другие сторы

Если приложение распространяется в России через RuStore или AppGallery, сборку для этих магазинов проверяйте отдельно. Обычно в ней нет зависимостей от Google Play Services, используются свои сервисы push-уведомлений и свои способы оплаты, поэтому регресс по push, входу и платежам нужно повторить на этой сборке. Конкретные требования магазины обновляют, так что перед отправкой сверьте актуальные правила в консоли разработчика каждого стора.

Что проверяют	App Store	Google Play
Ревью	Ручное ревью каждой сборки	Проверка перед публикацией, плюс требования к треку тестирования для новых личных аккаунтов
Стабильность	Краши на ревью — причина отклонения	Пороги Android vitals после релиза, влияют на видимость
Доступ ревьюера	Демо-аккаунт и рабочий бэкенд обязательны при наличии входа	Данные для доступа к закрытым разделам указываются в консоли
Приватность	Политика конфиденциальности в App Store Connect и в приложении	Политика конфиденциальности и раздел Data safety
Технические требования	Финальная, протестированная на устройстве сборка	Target API 36 с 31.08.2026, формат AAB, Play App Signing

Как выпускать без риска: поэтапный релиз, мониторинг и откат

Безопасный выпуск мобильного приложения — это раскатка новой версии на часть аудитории с возможностью остановиться, если что-то пошло не так. В отличие от сайта, мобильное приложение нельзя просто «откатить»: версия, которую пользователь уже установил, останется у него до следующего обновления. Поэтому защищаются заранее — дозированным выпуском и серверными переключателями.

• ☐ Staged rollout в Google Play: выпуск на небольшой процент пользователей с постепенным увеличением; раскатку можно остановить.
• ☐ Phased release в App Store: автоматическое обновление распределяется на 7 дней, выпуск можно поставить на паузу.
• ☐ Feature flags: рискованные функции включаются с сервера и так же выключаются, без новой сборки.
• ☐ Серверный kill-switch и принудительное обновление: возможность отключить сломанную функцию или потребовать обновиться до исправленной версии.
• ☐ План отката: кто принимает решение, кто собирает hotfix, сколько времени занимает срочная отправка на ревью.
• ☐ Мониторинг первых 72 часов: краши и ANR, отзывы в сторах, ошибки API, конверсия ключевых сценариев — регистрации, оплаты, целевого действия.

Главный инструмент отката в мобайле — быстрый hotfix: исправление, сборка, ускоренное ревью и снова поэтапный выпуск. Чтобы этот цикл занимал часы, а не недели, нужна команда, которая знает код и инфраструктуру проекта. Если своей команды нет, такую работу закрывает поддержка мобильного приложения на стороне подрядчика с договорённостью о сроках реакции на критичные инциденты.

Шаблон чек-листа тестирования мобильного приложения: «Да / Нет / Блокер»

Шаблон релизного чек-листа — это сводная таблица ключевых проверок, по которой принимается решение о выпуске. Скопируйте её в свой трекер или таблицу, назначьте ответственных и заполняйте статус для каждой сборки-кандидата.

Фаза	Проверка	Ответственный	Статус (Да / Нет / Блокер)
T-14	Объём релиза заморожен, перенос задач согласован	Продакт
T-14	План регресса и список критичных сценариев готовы	QA-лид
T-14	Парк устройств собран по аналитике аудитории	QA-лид
T-14	Target API и требования сторов проверены	Тимлид
T-7	Code freeze, собран release candidate с боевыми настройками	Тимлид
T-7	Smoke-тест сборки-кандидата пройден	QA
T-7	Регресс критичных сценариев на реальных устройствах пройден	QA
T-7	Обновление поверх прошлой версии без потери данных	QA
T-7	Платежи и встроенные покупки проверены	QA
T-7	Сеть, офлайн, прерывания, фон — без критичных дефектов	QA
T-7	Нет открытых багов с приоритетом «критичный»	QA-лид
T-7	Debug-флаги и тестовые эндпоинты выключены, секретов в сборке нет	Тимлид
T-7	Сбор крашей и аналитика работают в релизной сборке	Тимлид
T-3	Метаданные, скриншоты и описание соответствуют функционалу	Продакт
T-3	Политика конфиденциальности: в сторе и в приложении	Продакт
T-3	Data safety (Google Play) заполнен корректно	Продакт
T-3	Демо-аккаунт для ревью рабочий, бэкенд включён	Тимлид
T-3	Review Notes с пояснениями заполнены	Продакт
T-3	Сборка для RuStore и других сторов проверена отдельно	QA
T-0	Поэтапный выпуск настроен с небольшой доли аудитории	Продакт
T-0	Feature flags и kill-switch проверены	Тимлид
T-0	План отката и ответственные за hotfix определены	Тимлид
T+72 ч	Crash rate и ANR в пределах порогов Android vitals и прошлых версий	QA-лид
T+72 ч	Отзывы, ошибки API и конверсия ключевых сценариев в норме	Продакт

Правило go/no-go. Хотя бы один «Блокер» — релиз переносится, без исключений. «Нет» без блокера — решение продакта: риск записывается, у него появляется владелец и срок исправления. Выпуск возможен, только когда все пункты фаз T-7 и T-3 закрыты статусами «Да» или осознанно принятыми «Нет».

Частые ошибки при подготовке к релизу

Большинство неудачных релизов срываются не из-за сложных багов, а из-за пропущенных простых проверок. Вот ошибки, которые встречаются чаще всего:

• Тестируют только на эмуляторах. Производительность, камера, push и поведение в фоне на реальном устройстве отличаются — дефекты всплывают уже у пользователей.
• Не проверяют обновление поверх старой версии. Чистая установка работает, а у существующих пользователей после обновления пропадают данные или сессия.
• Выключенный бэкенд или просроченный демо-аккаунт на ревью. Ревьюер не может войти — сборку отклоняют, и релиз сдвигается на дни.
• Выпуск сразу на 100% аудитории. Ошибка, которую поймал бы поэтапный выпуск на малой доле пользователей, сразу достаётся всем.
• Нет мониторинга крашей до релиза. Сбор крашей подключают «потом», и первые часы после выхода команда работает вслепую.
• Проверяют только «счастливый путь». Обрыв сети, отказ в разрешении и неверный ввод остаются непроверенными.
• Забытые debug-флаги и тестовые эндпоинты. Релизная сборка ходит на тестовый сервер или показывает меню разработчика.
• Сорванный дедлайн target API. Обновление вовремя не выходит, а приложение со старым target перестаёт показываться новым пользователям на новых версиях Android.

Частые вопросы о тестировании мобильного приложения перед релизом

Сколько времени закладывать на тестирование перед релизом?

Начинать подготовку стоит примерно за две недели до даты выпуска: заморозить объём, собрать парк устройств, затем за неделю объявить code freeze и прогнать регресс на сборке-кандидате. Точный срок зависит от объёма изменений и числа платформ, но на ревью сторов и возможную повторную отправку всегда нужно оставлять запас в несколько дней.

Можно ли тестировать только на эмуляторах?

Нет. Эмуляторы подходят для быстрых проверок вёрстки и логики, но производительность, камера, push-уведомления, прерывания и работа в фоне на реальных устройствах ведут себя иначе. Перед релизом критичные сценарии обязательно прогоняют на реальных смартфонах, подобранных по аналитике аудитории.

Почему Apple отклоняет приложения чаще всего?

По данным App Store Transparency Report, в 2024 году Apple отклонила 1 931 400 из 7 771 599 отправок, и чаще всего — по категории Performance: 1 235 471 отклонение. Сюда относятся краши, незавершённые экраны и плейсхолдеры, а также нерабочий демо-доступ для ревьюера — всё это нарушает пункт 2.1 App Completeness.

Какой crash rate считается допустимым?

Для Android ориентир задают пороги Android vitals: заметные пользователю краши — не выше 1,09% в среднем и 8% на одну модель телефона, ANR — не выше 0,47% в среднем и 8% на модель. Google оценивает их за 28 дней и при превышении может снизить видимость приложения. Для iOS публичных порогов нет — сравнивайте показатели с прошлыми версиями.

Что такое поэтапный выпуск и зачем он нужен?

Поэтапный выпуск — это раскатка новой версии сначала на небольшую часть пользователей с постепенным расширением: staged rollout в Google Play и phased release в App Store. Он позволяет заметить краши и ошибки до того, как они затронут всю аудиторию, и остановить выпуск, пока готовится исправление.

Нужно ли закрытое тестирование в Google Play?

Для личных аккаунтов разработчика, созданных после 13 ноября 2023 года, — да: перед доступом к production нужно провести закрытое тестирование с не менее чем 12 тестировщиками непрерывно в течение 14 дней. Аккаунты организаций от этого требования освобождены, но закрытый трек всё равно полезен как последняя проверка перед релизом.