Тестирование мобильных приложений: виды тестов, реальные устройства и полный цикл QA

Тестирование мобильного приложения — это системная проверка функциональности, интерфейса, производительности, совместимости и безопасности продукта до выхода в сторы. Полноценный QA сочетает ручные и автоматические тесты на реальных устройствах iOS и Android. В Казахстане в 2026 году тестирование занимает 15–25% бюджета разработки: от 300 000 ₸ за MVP до 2 000 000 ₸ и выше за финтех-продукт.

Команда Applications.kz с 2007 года выпустила более 300 проектов для рынков Казахстана, ОАЭ и Таиланда — и ни один из них не уходил в App Store или Google Play без формализованного цикла тестирования. В этой статье разбираем, из чего этот цикл состоит, какие виды тестов реально нужны бизнесу и почему эмуляторы не заменяют физические смартфоны.

Что входит в QA мобильного приложения

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

• Анализ требований — тестировщик ищет противоречия и пробелы в ТЗ до того, как они превратятся в код;
• Тест-план и чек-листы — документ, фиксирующий, что, на чём и в каком порядке проверяется;
• Тестовые сценарии (тест-кейсы) — пошаговые инструкции с ожидаемым результатом для каждой функции;
• Функциональное и нефункциональное тестирование — сами проверки, о которых ниже;
• Баг-репорты — каждая ошибка описывается с шагами воспроизведения, скриншотами, логами и приоритетом;
• Регрессионные прогоны — повторная проверка после каждого исправления;
• Релизное тестирование — финальная валидация сборки, которая уходит в сторы, включая проверку по гайдлайнам Apple и Google.

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

Виды тестирования: что и зачем проверяется

Функциональное тестирование

Отвечает на вопрос «работает ли приложение так, как задумано». Проверяются регистрация и авторизация, основные пользовательские сценарии, формы, платежи, push-уведомления, deep links. Для казахстанских проектов сюда же входит специфика: корректность работы с номерами +7 (7XX), оплата через Kaspi и местные эквайринги, ввод казахских букв ә, ғ, қ, ң, ө, ұ, ү, һ, і в полях имени и поиска — на этом ломается удивительное количество приложений.

Нефункциональное тестирование

Приложение может «работать» и при этом быть непригодным. Поэтому отдельно проверяются:

• Производительность — скорость холодного старта, отклик интерфейса, расход батареи и памяти, поведение при слабом сигнале. В регионах Казахстана 4G нестабилен, поэтому мы всегда гоняем сценарии на эмулированном 3G и при обрыве сети;
• Юзабилити — логичность навигации, читаемость, доступность элементов под большой палец;
• Совместимость — версии ОС, диагонали экранов, вырезы, складные устройства;
• Локализация — для рынка KZ это минимум русский и казахский: переключение языка не должно ломать вёрстку, а длинные казахские строки — вылезать за кнопки;
• Безопасность — хранение токенов, шифрование трафика, защита от перехвата данных. Это отдельная дисциплина, которую мы подробно разобрали в статье о безопасности мобильных приложений.

Smoke, регресс и приёмочное тестирование

Smoke-тест — короткий прогон критических функций после каждой новой сборки: запускается ли приложение, проходит ли логин, открываются ли ключевые экраны. Регрессионное тестирование — полная перепроверка перед релизом, чтобы исправление одного бага не сломало три соседние функции. Приёмочное (UAT) — финальная проверка заказчиком по согласованным критериям. Все три обязательны, и пропуск любого из них рано или поздно стоит дороже, чем его проведение.

Ручные тесты и автоматизация: где граница

Ручное тестирование незаменимо там, где нужна человеческая оценка: новый функционал, юзабилити, исследовательские проверки «а что, если». Автоматизация выигрывает на повторяющихся задачах: регрессионные прогоны, smoke-тесты в CI/CD, проверка API. На практике мы автоматизируем регресс, когда продукт переходит в фазу регулярных обновлений — обычно после 3–4 релизов, когда ручной прогон начинает занимать больше двух дней. Как устроены UI-автотесты, какие фреймворки используются для Flutter и нативных приложений и когда автоматизация окупается, мы разобрали в отдельном материале про автотесты мобильного приложения.

Реальные устройства против эмуляторов

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

• эмулятор не воспроизводит реальный расход батареи, троттлинг процессора при нагреве и поведение при нехватке памяти;
• камера, биометрия, NFC, push-уведомления, Bluetooth и геолокация на эмуляторе работают условно или не работают вовсе;
• прошивки производителей (HyperOS у Xiaomi, One UI у Samsung) агрессивно убивают фоновые процессы — на «чистом» эмуляторе Android этого не увидеть, а в Казахстане Xiaomi и Samsung составляют большую часть Android-парка;
• реальная сеть казахстанских операторов с переходами 4G→3G→EDGE ведёт себя иначе, чем идеальный Wi-Fi рабочей станции.

Наш рабочий минимум для проектов на рынок Казахстана — 8–10 физических устройств: iPhone последних четырёх поколений (включая одну модель с минимально поддерживаемой iOS), Samsung A-серии и флагман S-серии, два-три Xiaomi/Redmi разных ценовых сегментов, Honor или Huawei и хотя бы один планшет. Для проектов под ОАЭ и Таиланд парк корректируется под локальную статистику устройств и обязательно дополняется проверкой арабской RTL-вёрстки или тайской типографики.

Этапы тестирования в цикле разработки

Грамотный QA распределён по всему проекту, а не сжат в неделю перед релизом:

1. До разработки — ревью ТЗ и макетов, подготовка тест-плана. Ошибка, найденная в требованиях, исправляется в десятки раз дешевле, чем в продакшене;
2. Во время спринтов — проверка каждой фичи по тест-кейсам сразу после реализации плюс smoke-тест каждой сборки;
3. Перед релизом — полный регресс на устройствах, проверка интеграций (платежи, SMS, аналитика), тест обновления с предыдущей версии — классическая зона дефектов, о которой забывают;
4. После релиза — мониторинг крашей через Crashlytics или Sentry, анализ отзывов в сторах, hotfix-процедура.

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

Сколько стоит тестирование приложения в Казахстане

Ориентиры по рынку Казахстана на 2026 год — при работе со студией или выделенным QA-специалистом:

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

Как устроен QA в Applications.kz

В наших проектах тестирование — обязательная часть процесса, а не опция в смете. Тестировщик подключается на этапе требований, каждая сборка проходит smoke-прогон, перед релизом выполняется регресс на парке физических устройств, а после публикации мы отслеживаем стабильность через краш-аналитику. Для продуктов с регулярными обновлениями настраиваем автотесты в CI/CD, чтобы каждый коммит проверялся автоматически.

За плечами студии более 300 проектов с 2007 года — для бизнеса в Казахстане, ОАЭ и Таиланде, под руководством директора Ивана Калиты. Если вы планируете запуск или хотите проверить качество уже работающего продукта, посмотрите, как мы строим разработку мобильных приложений в Алматы, или позвоните: +7 (707) 928-13-15. Смету с детализацией по этапам, включая объём QA, подготовим за 24 часа.

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

Можно ли обойтись без тестировщика, если разработчики сами проверяют свой код?

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

Сколько времени занимает тестирование перед релизом?

Полный регресс среднего приложения (30–50 экранов) на парке из 8–10 устройств занимает 3–7 рабочих дней с учётом исправления найденных дефектов и повторных прогонов. Smoke-тест одной сборки — 2–4 часа. Если регресс автоматизирован, прогон сокращается до нескольких часов машинного времени, а ручная работа остаётся только на новых функциях.

На скольких устройствах нужно тестировать приложение для рынка Казахстана?

Разумный минимум — 8–10 физических устройств: 3–4 iPhone разных поколений и 5–6 Android-смартфонов с упором на Samsung и Xiaomi, которые доминируют в казахстанском парке. Обязательно включить бюджетную модель с 3–4 ГБ памяти и устройство на минимально поддерживаемой версии ОС — именно там проявляется большинство проблем производительности.

Что делать, если приложение уже в сторах и пользователи жалуются на баги?

Начать с разового QA-аудита: за 1–2 недели специалист прогоняет приложение по чек-листу, собирает краш-логи и формирует приоритизированный реестр дефектов. Дальше дефекты исправляются волнами — сначала краши и блокирующие ошибки, затем остальное. Это стоит 150 000 – 400 000 ₸ и даёт объективную картину вместо хаотичных правок по отзывам.

Тестируете ли вы приложения, разработанные другой студией?

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