Как протестировать приложение перед публикацией: чек-лист

Тестирование мобильного приложения перед публикацией - это пять обязательных блоков проверок: основные сценарии на реальных устройствах (минимум 4-6 моделей и 2-3 версии ОС), поведение в «плохих» условиях (нет сети, отказ в разрешениях, звонок во время оплаты), установка поверх предыдущей версии, формальные требования стора (политика конфиденциальности, описание сбора данных, удаление аккаунта, скриншоты) и бета-тест на живых людях через TestFlight или внутренние треки RuStore и Google Play. На всё это нужно 5-10 рабочих дней и один человек, который ведёт единый список дефектов. Актуально на октябрь 2026 года.

По опыту Honey Hunters Digital приложение чаще всего уезжает в стор после одной проверки: разработчик прошёл главный сценарий на своём телефоне, всё работало. Через неделю приходят отзывы с одной звездой, и выясняется, что на Android 11 не открывается камера, при слабом интернете оплата уходит в бесконечный спиннер, а у половины пользователей после обновления обнулилась корзина. Исправить это дорого не из-за кода, а из-за цикла: правка, сборка, ревью в сторе, ожидание, пока люди обновятся. Ниже - рабочая последовательность проверок, матрица устройств, список «плохих» условий, требования модераторов и чек-лист из 22 пунктов, который можно распечатать и идти по нему перед каждой отправкой.

Короткий ответ: из чего состоит проверка перед публикацией

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

Суммарно это 5-10 рабочих дней для приложения средней сложности. Если срок сжат, сокращать нужно не блоки, а глубину внутри блока: проверить три устройства вместо шести можно, выкинуть проверку поведения без сети - нет.

Шаг 1. Матрица устройств: на чём реально нужно проверять

Для проверки достаточно 4-6 реальных устройств, подобранных не по новизне, а по разнице: один свежий флагман, один средний телефон 2-3 лет, один дешёвый аппарат с малым объёмом памяти, один маленький экран и один большой. Эмуляторы годятся для вёрстки и быстрых прогонов, но камеру, пуши, оплату, биометрию и поведение при слабом интернете проверяют только на живом железе.

Как собрать матрицу под свой проект:

1. Посмотрите в аналитику, а не в рейтинги. Если у вас уже есть сайт, откройте отчёт по устройствам и версиям ОС в Метрике: распределение по моделям и разрешениям у мобильной версии сайта и будущего приложения обычно близкое. Берите модели, которые суммарно дают 70-80% аудитории.
2. Версии ОС - две-три последние. На iOS две последние мажорные версии покрывают почти всех. На Android разброс шире: кроме актуальной версии проверьте ту, что стоит на недорогих устройствах, которым 3-4 года, и обязательно убедитесь, что приложение хотя бы запускается на минимальной версии, заявленной в сборке.
3. Экраны: маленький, стандартный и большой. Узкий экран ловит обрезанные кнопки и съехавшие подписи, большой - растянутые картинки и пустоты. Если в сторе заявлена поддержка планшетов, планшет проверяется отдельно: Apple смотрит скриншоты для iPad и отклоняет приложения, где интерфейс просто растянут.
4. Тёмная тема, крупный шрифт, альбомная ориентация. Три системные настройки, которые ломают вёрстку чаще всего. Включите в системе увеличенный размер текста и пройдите главный сценарий: в половине приложений на этом месте начинают наезжать друг на друга блоки.
5. Старая и медленная сборка. Проверьте запуск на устройстве, где почти нет свободной памяти: долгий холодный старт и падение при открытии тяжёлого экрана проявляются именно там.

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

Шаг 2. Дымовой тест и основные сценарии

Основные сценарии - это 5-8 путей, по которым пользователь приносит вам деньги или заявку, и каждый из них проходится целиком, от первого запуска до подтверждения. Начинать нужно с дымового теста: 15 минут, в течение которых вы проверяете, что приложение вообще имеет смысл тестировать дальше.

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

Дальше по каждому сценарию проверяются три вещи: счастливый путь, граничные значения и отмена. Счастливый путь - всё заполнено верно. Граничные значения - пустое поле, один символ, 300 символов, эмодзи, пробелы по краям, нули и отрицательные числа в количестве, дата в прошлом. Отмена - пользователь вышел с середины: свернул приложение на экране оплаты, нажал «назад» в середине регистрации, убил приложение из списка задач. После возврата он должен попасть в понятное состояние, а не на белый экран.

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

Шаг 3. Плохие условия: где приложения ломаются чаще всего

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

Минимальный список:

1. Нет интернета. Включите авиарежим и пройдите главный сценарий. Приложение должно показать внятное сообщение и кнопку «повторить», а не крутящийся индикатор без конца и не пустой экран.
2. Медленный и рвущийся интернет. Самое неприятное состояние: сеть есть, но отвечает за 10-20 секунд. Проверьте двойные нажатия: если пользователь нажал «оплатить» дважды, не должно уйти два платежа и не должно создаться два заказа.
3. Сеть пропала посередине. Отключите связь между отправкой заявки и ответом сервера. Пользователь должен узнать результат, а не остаться в неизвестности, и при повторной отправке дубля быть не должно.
4. Отказ в разрешениях. Запретите пуши, камеру, геолокацию, галерею - и по очереди, и все сразу. Приложение не должно падать и не должно блокировать функции, которые без этого разрешения работают. Отдельно проверьте путь «сначала запретил, потом разрешил в настройках».
5. Прерывания. Входящий звонок во время оплаты, будильник, уведомление сверху, шторка, переключение на другое приложение и возврат через 10 минут, блокировка экрана и разблокировка по биометрии. После возврата состояние экрана должно сохраниться.
6. Пустые и предельные данные. Новый аккаунт без истории, пустая корзина, поиск без результатов, список из одной записи и список из тысячи. Пустые экраны - это отдельная работа дизайнера, и чаще всего их просто забывают нарисовать.
7. Разрядка и фон. Оставьте приложение в фоне на час и вернитесь: токен не должен протухать молча, пуши должны приходить, данные - обновляться. Заодно посмотрите расход батареи и трафика на главном экране за 10 минут использования.
8. Смена времени и часового пояса. Для всего, где есть записи, брони и доставки: переведите время на устройстве и проверьте, не поехали ли даты.

Для сбоев обязательно подключите отчёты о падениях ещё до релиза и смотрите долю сессий без сбоев: рабочая норма - выше 99%. Если на тестовой сборке она ниже, публиковать нельзя, иначе первый же отзыв будет про закрывающееся приложение. Как увязать это с остальной аналитикой, мы разбирали в статье «Аналитика в мобильном приложении: какие события настроить до релиза».

Шаг 4. Обновление поверх старой версии, а не только чистая установка

Если приложение уже публиковалось, обновление нужно проверять отдельно от установки с нуля: именно на обновлении теряются данные, слетают сессии и падает приложение из-за изменившейся структуры локальной базы. Проверка простая: поставьте версию из стора, поработайте в ней (создайте заказ, добавьте товары в избранное, настройте профиль), и уже поверх неё установите новую сборку.

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

И ещё одна вещь, которую легко забыть: поведение старой версии после обновления сервера. Если вместе с приложением выходят изменения в API, убедитесь, что предыдущая версия приложения продолжает работать или показывает понятный экран «обновите приложение». В день релиза старая версия стоит у всей вашей аудитории, и обновится она за недели, а не за часы.

Шаг 5. Бета-тест на живых людях

Бета-тест нужен, чтобы увидеть то, что внутри команды не видно: непонятные формулировки, неочевидные кнопки и сценарии, которые пользователи проходят не так, как было задумано. Достаточно 10-30 человек и 3-7 дней, из них половина - люди вне команды, желательно из целевой аудитории.

Инструменты у каждой площадки свои. На iOS это TestFlight: внутренние тестировщики получают сборку сразу, внешние - после короткой проверки, и приглашать можно до 10 000 человек по ссылке. У Google Play есть закрытый, открытый и внутренний треки: внутренний раздаёт сборку ограниченному списку почти мгновенно. В RuStore сборку тоже можно раздать ограниченному кругу до публичной публикации. Важно, что в TestFlight и на закрытых треках стора вы отдаёте ровно ту сборку, которая поедет на модерацию, а не отдельную «тестовую»: это снимает целый класс сюрпризов.

Чтобы бета-тест дал результат, а не три сообщения «вроде работает», подготовьте три вещи. Первое - короткий список заданий: «зарегистрируйтесь, найдите товар, оформите заказ, отмените его». Второе - единый канал для обратной связи: один чат или одна форма, не личные сообщения в пяти мессенджерах. Третье - просьба писать модель телефона и версию ОС, иначе половина сообщений будет невоспроизводима. Дефекты складывайте в один список с приоритетом: блокирующие правятся до релиза, остальные уходят в следующую версию.

Что проверяют модераторы сторов и за что отклоняют

Модерация проверяет не качество кода, а полноту приложения и формальные требования: приложение не должно падать при запуске, все функции должны быть доступны проверяющему, а данные о сборе персональной информации - совпадать с реальностью. Большинство отклонений - не про сложное, а про забытое.

Что готовят до отправки:

1. Демо-доступ для проверяющего. Если в приложении есть вход, приложите тестовый логин и пароль и убедитесь, что аккаунт живой, а SMS-код не нужен. Приложение, в которое ревьюер не смог войти, отклоняют почти гарантированно.
2. Работающая ссылка на политику конфиденциальности. Открытая страница на вашем домене, доступная без авторизации, с описанием того, какие данные собираются и зачем. Про требования российского законодательства к таким документам мы писали в статье «152-ФЗ на сайте: политика, согласия и реальные штрафы».
3. Честная карточка сбора данных. В App Store Connect и Google Play заполняется декларация о данных. Если SDK аналитики собирает идентификатор устройства, а в декларации этого нет, приложение снимут с публикации уже после релиза.
4. Удаление аккаунта внутри приложения. Если пользователь может зарегистрироваться, он должен иметь возможность удалить аккаунт из приложения, а не письмом в поддержку. Это требование Apple, и на нём спотыкаются регулярно.
5. Скриншоты и описание, соответствующие приложению. Скриншоты снимаются с актуальной сборки в нужных размерах, без устаревших экранов, без упоминания других платформ и без функций, которых в приложении нет.
6. Возрастной рейтинг и контент. Анкета возрастного рейтинга заполняется честно; для RuStore дополнительно проверьте соответствие контента российским требованиям.
7. Оплата по правилам площадки. За цифровой контент внутри приложения на iOS используется встроенная покупка. Оплата физических товаров и услуг своим эквайрингом разрешена, но смешивать правила нельзя.
8. Никаких заглушек и «скоро будет». Нерабочие кнопки, пустые разделы и тексты-рыбы - прямое основание для отклонения как незавершённого приложения.

По срокам ориентируйтесь так: проверка в App Store обычно занимает от нескольких часов до 1-2 суток, в RuStore - до нескольких рабочих дней, в Google Play для новых аккаунтов разработчика проверка может растянуться на неделю и больше. Каждое отклонение добавляет круг, поэтому формальности дешевле закрыть заранее. Подробнее о процедуре публикации и требованиях площадок - в статье «Как опубликовать приложение в RuStore и App Store: сроки и требования».

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

Для приложения средней сложности тестирование перед публикацией занимает 5-10 рабочих дней и обычно укладывается в 10-15% трудозатрат проекта. Это не отдельная статья расходов «на потом», а часть сметы: тестирование, которое не заложили в план, всегда выполняется в день отправки и всегда наполовину.

Из обязательных платежей: аккаунт разработчика Apple стоит 99 долларов в год, регистрация разработчика в Google Play - разовые 25 долларов, в RuStore публикация для разработчика бесплатна. Аренда устройств в облачной фарме и ручное тестирование на рынке считаются по часам - вилки начинаются от нескольких сотен рублей за час аренды устройства и от 1 000-1 500 рублей за час работы тестировщика, но конкретная цифра зависит от города и подрядчика, поэтому обещать за рынок мы не берёмся.

Если приложение уже вышло, тестирование не заканчивается: каждое обновление ОС и каждая новая версия требуют повторного прогона основных сценариев. Это удобно держать внутри поддержки: базовый тариф Honey Hunters Digital начинается от 15 000 рублей в месяц и включает 4 часа работ и «Красную кнопку» на срочные ситуации, часы в этом тарифе не переносятся на следующий месяц. На больших тарифах час дешевле, а неизрасходованные часы переносятся - такой вариант обычно берут там, где релизы идут регулярно. Сколько стоит поддержка именно приложения, мы разбирали в статье «Сколько стоит поддержка мобильного приложения после запуска».

Чек-лист перед отправкой в стор: 22 пункта

Этот список имеет смысл пройти целиком за день до отправки сборки на модерацию. Если хотя бы один пункт из первых девяти не выполнен, отправлять рано.

1. Приложение устанавливается и запускается с чистого состояния на всех устройствах из матрицы.
2. Дымовой тест пройден полностью: онбординг, регистрация, вход, главный экран, ключевое действие, выход.
3. Все основные сценарии пройдены до подтверждения, включая оплату или отправку заявки.
4. Проверено поведение без интернета и при медленной сети, двойное нажатие не создаёт дублей.
5. Проверены отказы во всех разрешениях, приложение не падает и не блокируется.
6. Проверены прерывания: звонок, блокировка экрана, уход в фон и возврат.
7. Проверены пустые состояния: новый аккаунт, пустой список, поиск без результатов.
8. Обновление поверх предыдущей версии не теряет данные и авторизацию.
9. Доля сессий без сбоев на тестовой сборке выше 99%, критичных падений нет.
10. Вёрстка проверена на маленьком и большом экране, в тёмной теме и при увеличенном шрифте.
11. Пуши приходят и открывают нужный экран, в том числе при закрытом приложении.
12. Аналитика отправляет события, в отчётах видна воронка от запуска до ключевого действия.
13. В сборке нет тестовых данных, отладочных экранов, логов с персональными данными и адресов тестового сервера.
14. Ключи и токены не лежат в коде открытым текстом.
15. Версия и номер сборки увеличены, файл подписан рабочим сертификатом.
16. Демо-аккаунт для проверяющего создан, проверен и указан в заявке.
17. Ссылка на политику конфиденциальности открывается без авторизации.
18. Декларация о сборе данных совпадает с тем, что реально собирают SDK.
19. Удаление аккаунта доступно внутри приложения, если есть регистрация.
20. Скриншоты, иконка, название и описание сняты с актуальной сборки и соответствуют требованиям площадки.
21. Возрастной рейтинг заполнен, контент соответствует правилам площадок.
22. Бета-тест прошёл, блокирующие дефекты закрыты, остальные вынесены в план следующей версии.

Распечатайте список и отмечайте пункты руками. Кажется формальностью, но именно так находится забытый тестовый сервер в релизной сборке.

Если вы сейчас на этапе, когда приложение почти готово, а понимания «достаточно ли мы проверили» нет - приходите, посмотрим вместе. Мы собираем приложения целиком: от матрицы устройств и плана проверок до отправки на модерацию и первых недель после релиза, когда и вылезает основное. Расскажите, что у вас за проект, и мы честно скажем, где риск, а где можно не тратить время. Начать удобно со страницы разработки мобильных приложений или сразу через контакты.

И по-дружески: вопросы вроде «на скольких устройствах вы проверяете» или «сколько кругов модерации было у вас» лучше задавать тем, кто это уже проходил. Такие разговоры идут в нашем Telegram-канале «Тусовка владельцев сайтов» - без рекламы и с реальными цифрами от владельцев проектов.

Частые вопросы

Сколько времени нужно на тестирование приложения перед публикацией?
Для приложения средней сложности - 5-10 рабочих дней: 1-2 дня на устройства и основные сценарии, 1-2 дня на проверку плохих условий, полдня на формальности стора и 3-7 дней на бета-тест, который идёт параллельно с правками. Если срок сжат, сокращайте глубину внутри блоков, но не выбрасывайте блоки целиком.

Сколько устройств нужно для проверки?
Достаточно 4-6 реальных устройств, подобранных по разнице, а не по новизне: свежий флагман, средний телефон 2-3 лет, дешёвый аппарат с малой памятью, маленький и большой экран, плюс планшет, если его поддержка заявлена в сторе. Эмулятор подходит для вёрстки, но камеру, пуши, оплату и биометрию проверяют только на живом железе.

Можно ли обойтись эмуляторами вместо реальных устройств?
Нет. На эмуляторе не воспроизводятся поведение камеры и биометрии, доставка пушей, работа при слабой сети, расход батареи и реальная производительность на слабом железе. Эмулятор экономит время на проверке вёрстки и быстрых прогонах, но решение о публикации принимается по результатам на физических устройствах.

За что чаще всего отклоняют приложения на модерации?
За незавершённость и формальности: падение при запуске у проверяющего, отсутствие рабочего демо-доступа, нерабочая ссылка на политику конфиденциальности, декларация о сборе данных, не совпадающая с поведением SDK, отсутствие удаления аккаунта внутри приложения при наличии регистрации, скриншоты не от актуальной сборки и нерабочие кнопки с пометкой «скоро».

Нужно ли тестировать обновление отдельно от установки?
Обязательно, если приложение уже публиковалось. Именно на обновлении теряются локальные данные и сессии из-за изменившейся структуры базы. Проверяйте установку новой сборки поверх версии из стора, причём с двух предыдущих версий: часть пользователей обновляется редко и прыгает через релизы.

Что делать, если после релиза нашли критичную ошибку?
Сначала оцените долю затронутых пользователей по отчётам о сбоях и аналитике, затем выпускайте правку отдельной сборкой, не смешивая её с новым функционалом: такая сборка быстрее проходит проверку. В App Store для подтверждённых критичных ситуаций есть ускоренное рассмотрение, но запрашивать его стоит редко и по делу.