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

Что такое приёмка и чем она отличается от публикации

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

Почему приёмку нельзя делать за 10 минут

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

Проверка на устройствах

  • Не меньше двух-трёх реальных телефонов: недорогой Android, флагманский Android, iPhone, если приложение кросс-платформенное.
  • Разные размеры экранов: маленький телефон и большой, чтобы вёрстка не съезжала и текст не обрезался.
  • Медленный интернет и переключение между Wi-Fi и мобильной сетью: приложение не должно зависать или терять данные.
  • Полностью офлайн, если по техническому заданию это предусмотрено.
  • Свежая установка «с нуля» и обновление поверх предыдущей версии, если это не первый релиз.

Проверка пользовательских сценариев

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

  1. Регистрацию и вход, включая забытый пароль или код подтверждения по SMS.
  2. Основной сценарий: заказ, запись, оформление, в зависимости от типа приложения.
  3. Оплату: успешный платёж, отменённый платёж, платёж с ошибкой банка, чтобы приложение не зависало и показывало понятную ошибку.
  4. Push-уведомления: приходят ли они на реальное устройство, а не только в тестовой консоли.
  5. Пустые состояния: что видит пользователь, если заказов ещё нет или список отфильтрован в ноль.
  6. Ошибки сети: сообщение при пропавшем интернете, а не белый экран.
  7. Выход из аккаунта и повторный вход с другим пользователем.

Проверка админ-панели

Что проверить На что обратить внимание
Вход в админку Доступ под ролью владельца, а не только под демо-логином разработчика
Права ролей Администратор, менеджер, оператор видят и могут ровно то, что описано в ТЗ
Основные операции Добавление и редактирование товаров, заказов, пользователей без ошибок
Отчёты Данные в отчётах совпадают с тем, что реально происходит в приложении
Изменения в реальном времени Правка в админке сразу отражается в приложении, без задержки в сутки

Доступы, которые должны быть у вас, а не только у подрядчика

Это самый важный пункт приёмки, потому что его последствия проявляются не сразу, а через полгода-год, когда нужно что-то поменять, а доступов нет.

  • Аккаунт разработчика Apple и Google оформлен на компанию, а не на личный аккаунт сотрудника подрядчика, подробнее в статье про аккаунт разработчика Apple и Google.
  • Доступ администратора в Google Play Console и App Store Connect у ответственного сотрудника компании.
  • Данные для входа на сервер, где развёрнут backend: хостинг-провайдер, панель управления, база данных.
  • Домен приложения и связанные с ним DNS-записи оформлены на компанию.
  • Ключи и сертификаты, которыми подписаны сборки, переданы вместе с паролями.
  • Исходный код в репозитории, который принадлежит компании, а не личному аккаунту разработчика.

Если проект уже сдан, а часть доступов так и осталась у подрядчика, наведение порядка с ключами, аккаунтами и кодом это отдельная работа, которую можно заказать как аудит существующего приложения через доработку приложений.

Проверка push-уведомлений и уведомлений о заказах

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

  • Уведомление доходит до устройства, если приложение свёрнуто и если оно полностью закрыто.
  • Нажатие на уведомление открывает нужный экран, а не просто главную страницу приложения.
  • Уведомления не дублируются и не приходят с задержкой в часы вместо секунд или минут.
  • Пользователь может отключить отдельные типы уведомлений, если это предусмотрено в ТЗ.

Проверка платежей отдельным блоком

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

  1. Успешный платёж на реальную небольшую сумму, а не только в тестовом режиме платёжной системы.
  2. Отменённый пользователем платёж: приложение должно корректно вернуться в предыдущее состояние.
  3. Платёж с ошибкой банка, например недостаточно средств: пользователь видит понятную причину, а не техническую ошибку сервера.
  4. Повторная попытка оплаты после неудачной: не должно создаваться два заказа вместо одного.
  5. Чек или подтверждение заказа приходит клиенту тем способом, который описан в ТЗ, например в приложении и на почту.

Документация, которую нужно забрать вместе с кодом

  • Инструкция по сборке приложения: версия Flutter или нативного стека, зависимости, переменные окружения.
  • Схема базы данных или хотя бы список основных таблиц и их назначения.
  • Описание API backend, если приложение обменивается данными с сервером.
  • Инструкция для администратора по работе с панелью управления.
  • Список внешних сервисов и интеграций: Kaspi Pay, Firebase, карты, SMS-шлюз, с указанием, на чей аккаунт они оформлены.
  • Контакты ответственного разработчика или менеджера подрядчика на период гарантийной поддержки, если она предусмотрена договором.

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

Частые проблемы казахстанских компаний при приёмке

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

Что делать после приёмки, а не только до неё

Приёмка не заканчивается подписанием акта. В первые недели после выхода в стор стоит:

  • Наблюдать за отзывами в App Store и Google Play, они часто вскрывают проблемы, которые не встретились во время ручного тестирования.
  • Проверить, что аналитика в приложении действительно собирает события, а не просто установлена, но не настроена.
  • Уточнить у подрядчика гарантийный срок на исправление ошибок и зафиксировать его письменно, если это не сделано в договоре заранее.
  • Запланировать регулярное обновление приложения хотя бы раз в несколько месяцев, чтобы не отстать от новых версий Android и iOS.

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

Сколько времени нужно на приёмку приложения?

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

Что делать, если во время приёмки нашли ошибки?

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

Обязательно ли требовать исходный код при приёмке?

Да, если по договору права на приложение переходят заказчику. Получить код и доступы проще до оплаты последнего этапа, чем после.

Кто должен быть администратором аккаунта в Google Play и App Store?

Сотрудник компании-заказчика. Подрядчику для работы достаточно роли с ограниченными правами, а не полного владения аккаунтом.

Что если подрядчик тянет с передачей доступов после подписания акта?

Опирайтесь на пункты договора об исключительных правах и передаче материалов, и на переписку, где эти доступы обещаны. Если доступов так и нет, привлекайте другую команду для аудита и восстановления контроля над проектом.

Поможем принять работу у подрядчика

Проведём независимую проверку приложения перед подписанием акта: пройдём сценарии, проверим админ-панель, доступы и исходный код, укажем на риски до того, как деньги переведены. Аудит и доработка от 500 000 ₸. Оставьте заявку на странице контактов или в WhatsApp +7 707 928 13 15.