Аудит мобильного приложения: чек-лист перед редизайном или сменой команды

Сначала сформулируйте решение, а не список проверок

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

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

Соберите доказательства и проверьте доступы

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

Отдельно составьте таблицу владельцев. Кто контролирует App Store Connect и Google Play Console? На кого оформлены облако, домен, репозиторий, аналитика, рассылка уведомлений, платежный сервис и ключи подписи? Потерянный доступ способен остановить выпуск приложения. Это риск бизнеса, а не мелкая формальность. В руководстве по документации и передаче приложения перечислено, что должна получить новая команда.

Проверьте основные сценарии на настоящих устройствах

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

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

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

Не делайте выводы по воронке, пока не проверили события

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

Тестовые данные не должны смешиваться с рабочими. Версия приложения должна быть видна в отчетах, а iOS и Android — использовать одинаковый смысл событий. Пока измерение ненадежно, выводы о воронке следует считать предварительными. Базовую схему измерения мы разбираем в руководстве по аналитике мобильного приложения.

Оцените сбои и скорость в контексте

Общего числа сбоев мало. Разделите их по версии, системе, модели устройства, рынку и сценарию. Android Vitals показывает сбои и зависания ANR, с которыми столкнулись пользователи. В документации Android Vitals описаны основные показатели и проблемы отдельных моделей. Для iOS полезны данные App Store Connect App Analytics об установках, использовании и производительности.

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

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

Проследите действие от экрана до базы данных

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

Возьмите два важных сценария и пройдите их по всей цепочке: мобильный код, API, база данных, внешние сервисы. Где проверяются данные? Что происходит при повторном запросе? Как устроены кэш и миграции? Можно ли безопасно откатить изменение? Так нередко обнаруживается, например, создание двух заказов после восстановления связи.

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

Попросите команду показать выпуск, а не рассказать о нем

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

Убедитесь, что компании принадлежат права на код, дизайн, шрифты, изображения и платные библиотеки. Основные учетные записи должны быть оформлены на бизнес, а сотрудники — получать личные права по ролям. Общий пароль от частной почты не заменяет нормальную передачу проекта.

Разделите выводы на пять понятных действий

Оценивайте серьезность и уверенность отдельно. Возможная ошибка оплаты, которую пока не удалось повторить, требует быстрой проверки. Но она еще не доказывает, что весь продукт нужно писать заново.

Для каждого компонента выберите действие:

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

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

Что должно остаться после аудита

В финальном документе нужны границы работы, список доказательств, текущая архитектура, результаты тестов, оценка достоверности аналитики, исходные показатели стабильности, потерянные доступы, приоритеты и план по этапам. У каждого существенного пункта укажите последствия, доказательство, рекомендацию, зависимость, ответственного и примерный объем.

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

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

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