Даже если в команде ещё нет штатного QA-инженера, владелец продукта может и должен проверять приложение до выхода к пользователям. Грамотный самостоятельный аудит мобильного приложения позволяет выявить критические баги, UX-проблемы и несоответствия ТЗ ещё до первых отзывов в сторах.
Смотрите также: тестирование программного обеспечения — профессиональный QA под ключ.
По опыту нашей команды в YuSMP Group: большинство критических багов, которые доходят до продакшена, — это не сложные edge-cases, а элементарные пропуски в проверке совместимости и работы без интернета. Час прогона по чек-листу на двух-трёх устройствах перед релизом закрывает значительную часть таких рисков.
Зачем тестировать мобильное приложение перед релизом
Баг, найденный на этапе разработки, обходится в разы дешевле, чем в проде. Негативные отзывы в App Store и Google Play снижают конверсию загрузок, а поднять рейтинг после падения крайне трудоёмко. Поэтому базовый функциональный аудит перед релизом — обязательный шаг для любого продукта.
Виды тестирования мобильных приложений
Не каждый вид тестирования требует технических навыков. Таблица ниже поможет понять, что можно сделать самостоятельно, а что лучше отдать профессиональному QA.
| Вид тестирования | Что проверяет | Кто делает | Инструменты |
|---|---|---|---|
| Функциональное | Логика по ТЗ: кнопки, формы, переходы | Владелец продукта | Руки + чек-лист |
| UX-тестирование | Насколько интуитивен интерфейс | Владелец + фокус-группа | Запись экрана, реальные пользователи |
| Совместимость | Разные устройства и версии OS | QA-инженер | BrowserStack, Firebase Test Lab |
| Нагрузочное | Поведение под пиковой нагрузкой | QA-инженер | JMeter, Gatling, k6 |
| Безопасность | Защита данных, авторизация, шифрование | QA / разработчик | OWASP Mobile Top 10, ZAP |
| Регрессионное | Не сломали ли новые функции старые | QA-инженер | Appium, Detox, XCUITest |
Что можно проверить самостоятельно: чек-лист
- Регистрация и авторизация. Все способы входа (email, телефон, соцсети) работают без ошибок.
- Основные user flow. Ключевые сценарии — оформить заказ, записаться, отправить форму — проходят насквозь без зависаний.
- Навигация. Кнопки «Назад», вкладки и меню реагируют корректно, приложение не теряет состояние.
- Работа без интернета. Приложение не «падает» при потере соединения — показывает понятное сообщение об ошибке.
- Граничные значения форм. Поля корректно обрабатывают пустой ввод, длинные строки и спецсимволы — без белого экрана.
- Push-уведомления. Разрешение запрашивается уместно, уведомления открывают нужный экран.
- Ориентация экрана. Поворот устройства не ломает вёрстку.
- Тёмная тема. Текст читаем, иконки видны, контраст достаточный.
- Разные устройства. Проверка хотя бы на двух физических устройствах с разными OS-версиями.
- Соответствие ТЗ. Каждая задокументированная функция реализована так, как описано.
Пошаговый процесс тестирования мобильного приложения
- Составьте список сценариев. На основе ТЗ выпишите все ключевые пути пользователя и негативные сценарии (ошибки ввода, потеря сети).
- Пройдите каждый сценарий. Выполняйте шаги так, как будет делать реальный пользователь — без знания кода и архитектуры.
- Фиксируйте дефекты. Для каждого бага записывайте: устройство, OS-версию, шаги воспроизведения, ожидаемый и фактический результат.
- Расставьте приоритеты. Критические баги (краш, потеря данных) — в первую очередь; косметика — в backlog.
- Перепроверьте после фиксов. После исправления убедитесь, что смежные сценарии не сломались (минирегрессия).
- Подготовьте отчёт. Список проверенных сценариев, найденные баги со статусами, рекомендация по готовности к релизу.
Как проверить совместимость, если нет парка устройств
Фрагментация Android — десятки производителей, версий OS и разрешений экрана — остаётся главной причиной багов совместимости. Полноценная лаборатория устройств есть не у каждой команды, но проверить совместимость можно и без неё — тремя способами.
| Способ | Что даёт | Ограничения | Когда использовать |
|---|---|---|---|
| Реальные устройства | Точные данные по производительности, датчикам, камере | Нужно физически иметь технику | Финальная проверка перед релизом |
| Эмуляторы и симуляторы | Быстрый бесплатный запуск в Android Studio / Xcode | Не всегда точно повторяют поведение батареи, GPS, камеры | Разработка и ранние итерации |
| Облачные фермы | Firebase Test Lab, BrowserStack — сотни моделей без закупки | Платно при больших объёмах, очередь на устройство | Проверка совместимости перед крупным релизом |
Для самостоятельного аудита достаточно двух физических устройств — флагмана и бюджетной модели с разными версиями OS — плюс один прогон через облачную ферму на моделях, которые реально используют ваши пользователи (это видно в аналитике).
Как проверить базовую безопасность приложения без ИБ-специалиста
Полноценный пентест требует профильных специалистов, но часть проверок из OWASP Mobile Top 10 доступна и без них — уже на этапе самостоятельного аудита:
- HTTPS везде. Все запросы к API идут по HTTPS, а не HTTP — проверьте через прокси-инструмент (Charles Proxy, mitmproxy).
- Права доступа по минимуму. Приложение запрашивает только те разрешения (камера, геолокация, контакты), которые реально использует функциональность.
- Нет секретов в коде. API-ключи, токены и пароли не зашиты в открытом виде в сборке APK/IPA — распакуйте её и проверьте строки.
- Безопасное хранение данных. Токены авторизации и персональные данные не лежат в открытом SharedPreferences/UserDefaults без шифрования.
- Корректный выход из сессии. После logout токен реально аннулируется на сервере, а не только удаляется на клиенте.
- Защита от обратной разработки. Критичная логика (расчёт цены, проверка подписки) не выполняется целиком на клиенте — иначе её легко обойти декомпиляцией.
Тестирование локализации: что проверить в мультиязычном приложении
Если приложение работает только на один рынок и один язык, этот блок можно пропустить. Для мультиязычных продуктов локализация — частый источник багов, которые не ловит обычное функциональное тестирование:
- Тексты не обрезаются и не наезжают друг на друга при переводе на языки с более длинными словами (немецкий, финский).
- Даты, валюта и разделители чисел форматируются по локали устройства, а не зашиты хардкодом.
- Для RTL-языков (арабский, иврит) интерфейс зеркалируется целиком, а не только текст.
- Push-уведомления и email-рассылки приходят на языке, выбранном в приложении, а не системном языке устройства.
Типичные ошибки при самостоятельном аудите
- Тестировать только на одном устройстве — пропускаются проблемы совместимости.
- Проверять только happy path — негативные сценарии (ошибки, отсутствие сети) остаются непроверенными.
- Не фиксировать дефекты письменно — воспроизведение забудется через несколько дней.
- Начинать тестирование за день до релиза — нет времени на исправления.
- Игнорировать доступность (accessibility) — для широкой аудитории это репутационный и юридический риск.
Когда нужен профессиональный QA-аудит
Обратиться к QA-инженерам стоит, если приложение работает с персональными или финансовыми данными (нужен аудит безопасности), ожидается нагрузка от тысячи одновременных пользователей (нагрузочное тестирование), или выходят регулярные релизы и без автоматизации регрессия «съедает» всё больше времени команды.
Частые вопросы о тестировании мобильных приложений
Можно ли провести аудит мобильного приложения без QA-инженера?
Да, функциональный аудит по чек-листу доступен владельцу продукта или менеджеру. Нагрузочное тестирование, автоматизация регрессии и аудит безопасности требуют технических компетенций — их лучше доверить профессиональному QA.
Как протестировать приложение на разных устройствах без большого парка техники?
Используйте облачные сервисы: Firebase Test Lab (бесплатно для Android в ограниченном объёме) или BrowserStack. Для первоначального аудита достаточно двух физических устройств — флагмана и бюджетной модели разных производителей.
Чем отличается тестирование от аудита мобильного приложения?
Тестирование — это проверка конкретных сценариев в рамках разработки. Аудит мобильного приложения — более широкая оценка: включает анализ кода, архитектуры, безопасности, производительности и соответствия требованиям.
Сколько времени занимает базовое тестирование мобильного приложения?
Функциональный аудит небольшого приложения (10–20 экранов) по чек-листу занимает 4–8 часов. Полноценное тестирование с проверкой совместимости, безопасности и нагрузочного поведения — от 2 до 5 рабочих дней.
Что такое smoke-тестирование мобильного приложения?
Smoke-тест — быстрая проверка, что приложение запускается и ключевые функции работают без критических сбоев. Это первый шаг перед полноценным тестированием: если smoke-тест провалился, детальная проверка нецелесообразна.
Что обязательно проверить в безопасности приложения, если в команде нет ИБ-специалиста?
Минимальный набор: все запросы к API идут по HTTPS, приложение запрашивает только реально нужные разрешения, в коде нет захардкоженных API-ключей и паролей, токены и персональные данные хранятся зашифрованными, а logout аннулирует сессию на сервере, а не только на клиенте.
Нужно проверить качество продукта?
Настроим тестирование и автотесты — найдём баги до пользователей.
