Как мы тестируем мобильные приложения перед запуском

Почему тестирование мобильных приложений сложнее, чем кажется

Когда клиент говорит «просто проверьте, что всё работает» — за этой фразой скрывается несколько сотен сценариев, десятки устройств и платформ, разные версии операционных систем и непредсказуемые условия сети.

Мобильное приложение работает не в контролируемой среде браузера. Оно работает в кармане у пользователя: во время звонка, при низком заряде, в метро с нестабильным 4G, на дешёвом Android-устройстве 2021 года. Каждое из этих условий — потенциальный источник падения или баги, которую не увидели в офисе.

Цифры, которые говорят сами за себя: по данным аналитиков, 71% пользователей удаляют приложение после первого краша. Средняя стоимость исправления бага в продакшне в 6–15 раз выше, чем на этапе тестирования. А рейтинг приложения в App Store или Google Play, упавший из-за волны негативных отзывов, восстанавливается месяцами.

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

Этап 1: ручное тестирование и исследовательское тестирование

Автоматизация не заменяет человека. Особенно там, где важно «почувствовать» продукт: насколько удобна навигация, естественны ли анимации, не путает ли пользователя формулировка кнопки.

Ручное тестирование охватывает три основных направления:

Функциональное тестирование — проверка каждого сценария использования по тест-кейсам. Регистрация, авторизация, основные пользовательские пути, крайние случаи (пустые поля, некорректный ввод, отказ сервера). Каждый сценарий описан заранее с ожидаемым результатом.

UI/UX тестирование — соответствие дизайну, корректное отображение на разных разрешениях экрана, поведение при смене ориентации, доступность для пользователей с особыми потребностями (размер шрифта, контраст, поддержка скринридеров).

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

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

Этап 2: автоматизированное тестирование

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

Мы строим автоматизированное тестирование на трёх уровнях:

CI/CD-интеграция. Все автотесты запускаются автоматически при каждом пул-реквесте. Если юнит-тесты падают — ветка не мёрджится. Это убирает класс проблем «сломал что-то в другом месте, не заметил».

Snapshot-тестирование для Flutter и React Native позволяет фиксировать визуальное состояние компонентов и отлавливать непреднамеренные изменения в UI — когда дизайн «поехал» после правки, не связанной с интерфейсом.

Этап 3: тестирование на реальных устройствах

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

Минимальная матрица устройств для релиза:

Почему бюджетные устройства в приоритете для рынка Узбекистана и СНГ? По данным аналитиков, более 60% пользователей в регионе используют Android-устройства ценовой категории до $200. Приложение, которое прекрасно работает на флагмане, может лагать или падать на Redmi Note с 3 ГБ оперативной памяти. Это нужно знать до релиза, а не после.

Для облачного тестирования на широкой матрице устройств мы используем Firebase Test Lab и BrowserStack — они дают доступ к сотням реальных устройств без необходимости держать физический парк.

Этап 4: тестирование производительности

Производительность — это не про «работает быстро». Это про то, как приложение ведёт себя в условиях, далёких от идеальных.

Метрики, которые мы измеряем:

• Время холодного старта — от нажатия иконки до готовности к работе. Норма: до 2 секунд для Android, до 1,5 секунды для iOS
• Время отклика UI — от действия пользователя до визуальной реакции. Критично для списков, анимаций, прокрутки: порог — 16 мс (60 fps)
• Потребление памяти — типичный сеанс не должен выходить за разумные пределы для целевых устройств
• Расход батареи — фоновые процессы, геолокация, пуш-уведомления при неоптимальной реализации могут садить батарею заметно быстрее нормы
• Поведение при слабой сети — 2G, нестабильный 3G, переключение между Wi-Fi и мобильным интернетом

Инструменты: Android Profiler, Xcode Instruments, Firebase Performance Monitoring, Charles Proxy для эмуляции плохой сети.

Типичная ошибка: тестировать производительность только на Wi-Fi и флагманах. Реальный пользователь из Ферганы или Самарканда открывает приложение на Xiaomi Redmi 9 с 4G в час пик. Именно для него и нужно оптимизировать.

Этап 5: тестирование безопасности

Безопасность мобильного приложения — это не только HTTPS. Это целый пласт уязвимостей, специфичных именно для мобильной платформы.

Что мы проверяем:

Хранение данных на устройстве. Токены, пароли и персональные данные не должны храниться в открытом виде в SharedPreferences, UserDefaults или логах приложения. Это одна из самых распространённых уязвимостей в мобильных приложениях.

Передача данных. Проверка корректной реализации TLS, отсутствия certificate pinning bypass, защиты от man-in-the-middle атак через Charles или mitmproxy.

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

Защита кода. Обфускация и минификация для Android (ProGuard / R8), защита от реверс-инжиниринга, отсутствие чувствительных данных в бинарнике (API-ключи, хардкод паролей).

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

Этап 6: регрессионное тестирование и финальный чеклист

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

Регрессионный набор формируется из:

• Всех автоматизированных тестов
• Ручных тест-кейсов по критичным флоу
• Тестов, написанных по закрытым багам (чтобы они не вернулись)

Финальный чеклист перед релизом — документ, который подписывается QA-лидом и тимлидом разработки. Без него приложение не уходит в стор.

Что входит в чеклист:

• Все критичные и высокоприоритетные баги закрыты
• Автотесты зелёные на целевых платформах
• Тестирование на реальных устройствах из матрицы пройдено
• Производительность в пределах установленных норм
• Версия API совместима с текущим бэкендом
• Скриншоты и метаданные для App Store / Google Play актуальны
• Аналитика и crash reporting (Firebase Crashlytics / Sentry) подключены и работают
• Deep links и push-уведомления проверены на обеих платформах

Средний объём регрессионного набора для приложения с 6-месячной историей — 150–300 тест-кейсов. Полный ручной прогон занимает 2–3 дня. Именно поэтому автоматизация — не опция, а необходимость, начиная с определённого объёма проекта.

Итог

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

Шесть этапов, которые мы проходим перед каждым релизом:

• Ручное тестирование — функциональное, UI/UX и исследовательское
• Автоматизация — юниты, интеграционные и E2E-тесты в CI/CD
• Реальные устройства — матрица с акцентом на бюджетный сегмент
• Производительность — холодный старт, память, батарея, слабая сеть
• Безопасность — OWASP Mobile Top 10, хранение данных, передача, код
• Регрессия и финальный чеклист — формальное подтверждение готовности к релизу

Хорошее мобильное приложение не то, которое не падает у разработчика на MacBook. Хорошее приложение — то, которое стабильно работает у конечного пользователя в реальных условиях. Именно для этого и существует весь этот процесс.