Функциональное тестирование мобильного приложения: что проверять

Стандарт качества ПО ISO/IEC 25010:2023 называет первой характеристикой продукта функциональную пригодность — степень, в которой он выполняет функции, отвечающие заявленным и подразумеваемым потребностям в заданных условиях. Проверка этой характеристики и есть функциональное тестирование: в глоссарии ISTQB оно определено как тестирование на соответствие функциональным требованиям. Цена пропущенного функционального бага в мобайле измеряется буквально: если ошибка роняет приложение, Google Play учитывает это в Android vitals, и при доле заметных пользователю крашей выше 1,09% в среднем или 8% на одной модели телефона магазин может снизить видимость приложения и показать предупреждение в карточке.

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

Ниже — карта того, что проверять по зонам приложения, техники тест-дизайна с мобильными примерами, шаблон тест-кейса, пошаговый процесс, функциональные отличия iOS и Android, выбор между ручными проверками и автотестами и короткий чек-лист. Обзор всех видов тестирования — от нагрузочного до юзабилити — мы разбирали в статье «Виды тестирования мобильных приложений», а решение «выпускаем или нет» вместе с требованиями сторов — в чек-листе тестирования перед релизом. Здесь фокус только на функциональности.

Что такое функциональное тестирование мобильного приложения

Функциональное тестирование мобильного приложения — это проверка того, что каждая функция приложения делает то, что описано в требованиях, и выдаёт правильный результат при правильных и неправильных действиях пользователя. Оно отвечает на вопрос «что делает приложение», а не «как быстро» или «насколько удобно». ISO/IEC 25010 раскладывает функциональную пригодность на три подхарактеристики, и каждую можно проверить на мобильном примере:

• Функциональная полнота — все ли нужные функции есть. Пример: в ТЗ банковского приложения заявлен перевод по номеру телефона, а в сборке есть только перевод по реквизитам — функция отсутствует.
• Функциональная корректность — правильный ли результат. Пример: при промокоде на 10% и бесплатной доставке от 3000 ₽ корзина на 3100 ₽ после скидки должна снова показать платную доставку, а показывает бесплатную.
• Функциональная уместность — помогают ли функции решить задачу пользователя. Пример: чтобы повторить прошлый заказ, приходится заново собирать корзину, хотя сценарий «повторить заказ» описан в user story.

Основа для проверок — требования в любой форме: ТЗ, спецификация, user story с критериями приёмки, макеты и прототипы. Если требований нет или они расплывчаты, первая задача тестировщика — превратить их в проверяемые утверждения вместе с аналитиком или продактом. Функциональные проверки обычно проводят методом «чёрного ящика»: тестировщик не смотрит в код, а сравнивает поведение приложения с ожидаемым.

Чем функциональное тестирование отличается от нефункционального

Функциональное тестирование проверяет, что делает приложение, а нефункциональное — как оно это делает: быстро ли, надёжно ли, безопасно ли и удобно ли. Простой вопрос-тест: если ответ «работает / не работает по требованиям» — это функциональная проверка; если ответ — число, оценка или уровень, это нефункциональная.

Критерий	Функциональное тестирование	Нефункциональное тестирование
Что проверяет	Что делает приложение: функции и бизнес-логику	Как работает приложение: скорость, стабильность, безопасность, удобство
Примеры	Вход по SMS, расчёт корзины, оплата, push ведёт на нужный экран	Время холодного старта, расход батареи, нагрузка на сервер, юзабилити
Вопрос-тест	«Функция выполняется по требованию?»	«Насколько хорошо она выполняется?»
Основа	ТЗ, user story, критерии приёмки	Нефункциональные требования, метрики, стандарты
Когда проводят	С первой сборки функции и на каждой сборке	Когда функциональность стабилизировалась, перед релизом и после крупных изменений
Кто	QA-инженеры, продакт на приёмке	QA-инженеры, инженеры по производительности и безопасности, UX-исследователи
Инструменты	TestRail, Qase, Espresso, XCUITest, Appium, Maestro	Android Profiler, Xcode Instruments, нагрузочные инструменты, сканеры безопасности

На практике граница размыта. Работа без сети — функциональная проверка, если в требованиях сказано «заказ сохраняется в очередь и отправляется при появлении сети», и нефункциональная, если речь о том, сколько времени занимает синхронизация. С прерываниями так же: «после входящего звонка введённые данные сохраняются» — это функция, которую надо проверить в функциональном прогоне.

Что проверять при функциональном тестировании мобильного приложения

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

Установка, первый запуск и онбординг

• Приложение устанавливается и открывается на чистом устройстве, первый экран соответствует макету.
• Онбординг проходится до конца, его можно пропустить, и он не появляется повторно без причины.
• Выбор языка, региона или города на старте сохраняется и влияет на контент.
• Обновление со старой версии сохраняет данные, настройки и сессию пользователя.
• Принудительное обновление (force update) срабатывает для версий, которые сервер считает устаревшими.

Регистрация, вход и восстановление доступа

• Регистрация по телефону или e-mail: код из SMS или письма приходит, принимается один раз и истекает по таймауту.
• Повторная отправка кода доступна только после таймера, лимит попыток работает и понятно объясняется.
• Вход по биометрии (Face ID, отпечаток) включается, выключается и корректно откатывается на PIN или пароль.
• Вход через сторонние сервисы (Sign in with Apple, VK ID, Яндекс ID и другие) создаёт или привязывает правильный аккаунт.
• Восстановление пароля, выход из аккаунта и вход с другого устройства: старая сессия завершается, если так требует логика.
• Удаление аккаунта из приложения действительно удаляет или обезличивает данные.

Навигация, жесты и deep links

• Таб-бар, меню и переходы ведут на нужные экраны, стек экранов не ломается при быстрых переходах.
• Системная кнопка или жест «Назад» на Android и свайп от края на iOS возвращают на предыдущий экран, а не закрывают приложение.
• Pull-to-refresh, свайпы карточек, долгое нажатие и масштабирование работают так, как описано.
• Universal Links (iOS) и App Links (Android) открывают нужный экран и в запущенном, и в закрытом приложении; без установленного приложения ведут на сайт или в стор.
• Deep link на экран, требующий входа, сначала просит авторизацию, а после неё открывает исходную цель.

Формы и ввод данных

• Валидация полей: обязательность, формат, длина, понятные сообщения об ошибках рядом с полем.
• Маски телефона, карты и даты; правильный тип клавиатуры для каждого поля (цифры, e-mail, телефон).
• Вставка из буфера обмена, автозаполнение кода из SMS и паролей из менеджера.
• Эмодзи, Unicode, пробелы в начале и в конце, ввод на разных раскладках.
• Черновик длинной формы сохраняется при сворачивании, звонке и повороте экрана.

Бизнес-логика и расчёты

• Цены, скидки, промокоды, бонусы и доставка считаются по правилам — в том числе при их сочетании.
• Корзина: добавление, изменение количества, удаление, товар закончился во время оформления.
• Статусы заказа, записи или заявки меняются в правильном порядке и отображаются одинаково в приложении, push и на сайте.
• Роли и права: гость, клиент, сотрудник, администратор видят и могут делать только своё.
• Округления, валюты, часовые пояса в расчётах сроков и стоимости.

Платежи и встроенные покупки

• Успешная оплата, отказ банка, отмена пользователем, таймаут платёжной формы.
• Обрыв сети во время оплаты: нет двойного списания, статус заказа восстанавливается.
• Возврат средств и отмена заказа отражаются в истории.
• Встроенные покупки и подписки: покупка, продление, отмена, восстановление покупок на новом устройстве.
• Проверка в песочницах: StoreKit на iOS и тестовые аккаунты Play Billing на Android — без реальных списаний.

Push-уведомления и фоновые задачи

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

Разрешения устройства

• Запрос камеры, геолокации, контактов, микрофона и уведомлений появляется в момент, когда функция действительно нужна.
• Сценарий отказа: функция объясняет, зачем ей доступ, и предлагает перейти в настройки, а приложение не падает.
• Вариант «только один раз» и приблизительная геолокация: функция работает с ограниченным доступом.
• Отзыв разрешения в системных настройках во время работы приложения обрабатывается без краша.

Работа без сети и синхронизация

• Без сети приложение показывает понятное состояние и кешированные данные, а не пустой экран.
• Действия, сделанные офлайн, попадают в очередь и отправляются, когда сеть появляется.
• Конфликты синхронизации (те же данные изменены на двух устройствах) решаются по описанному правилу.
• Повторная отправка запроса после ошибки не создаёт дублей заказов и сообщений.

Интеграции и API

• Ответы сервера 4xx и 5xx показываются пользователю понятным сообщением, а не техническим текстом.
• Пустые ответы, неполные данные и неожиданные поля не ломают экран.
• Истёкший токен обновляется незаметно для пользователя или ведёт на повторный вход.
• Старая версия приложения корректно работает с новой версией API или получает предложение обновиться.
• Интеграции со сторонними сервисами — карты, доставка, чат поддержки — отрабатывают и при их недоступности.

Позитивные и негативные сценарии

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

Граничные случаи, которые чаще всего забывают:

• Пустые состояния: нет заказов, нет избранного, пустой результат поиска — экран объясняет, что делать дальше.
• Максимальная длина: очень длинное имя, адрес или комментарий не ломают вёрстку и сохраняются целиком или обрезаются по правилу.
• Смена даты, времени и часового пояса на устройстве — таймеры, сроки доставки и история не «съезжают».
• Смена языка системы посреди сессии и длинные строки перевода.
• Поворот экрана посреди ввода — данные формы не теряются.
• Двойной тап по кнопке оплаты или отправки — второй запрос не создаёт дубль.
• Истёкший токен после долгого простоя в фоне — пользователь не теряет введённые данные.
• Возврат из фона через несколько часов, когда система уже выгрузила процесс из памяти.

Какие техники тест-дизайна использовать

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

Классы эквивалентности

Классы эквивалентности — это группы входных значений, которые приложение должно обрабатывать одинаково; из каждой группы достаточно проверить одно значение. Пример: поле «Возраст» в приложении доставки алкоголя принимает значения от 18 до 120. Классы: меньше 18 (отказ), от 18 до 120 (принимается), больше 120 (ошибка ввода), нечисловое значение (ошибка). Четыре проверки вместо сотни. Для промокода классы — действующий, истёкший, уже использованный, несуществующий и чужой (выдан другому пользователю).

Анализ граничных значений

Анализ граничных значений — это проверка значений на краях классов эквивалентности, потому что ошибки чаще всего прячутся именно там: разработчик написал «<» вместо «<=». Пример: пароль должен содержать от 8 до 64 символов. Проверяем 7 (отказ), 8 (принимается), 64 (принимается) и 65 (отказ). Та же логика применяется к сумме заказа для бесплатной доставки, количеству товаров в корзине и времени жизни кода из SMS.

Таблица решений

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

Доставка	Оплата	Промокод	Ожидаемый результат
Курьер	Картой онлайн	Есть	Скидка применена, оплата онлайн, заказ оформлен
Курьер	Наличными курьеру	Есть	Скидка применена, оплата при получении
Самовывоз	Картой онлайн	Нет	Без скидки, оплата онлайн, адрес пункта выдачи в заказе
Самовывоз	Наличными курьеру	—	Вариант недоступен, приложение предлагает другой способ оплаты

Таблица сразу показывает недопустимые комбинации — например, оплату курьеру при самовывозе. Такие строки становятся отдельными негативными тест-кейсами.

Переходы состояний

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

Попарное тестирование (pairwise)

Попарное тестирование — это техника для большого числа параметров, при которой проверяются все пары значений, а не все комбинации целиком. Если нужно покрыть 3 версии ОС, 2 темы оформления и 3 языка интерфейса, полный перебор даёт 18 комбинаций, а набор, где каждая пара значений встречается хотя бы раз, — около 9. Наборы генерируют инструментами вроде PICT. Техника хорошо работает для матриц совместимости и настроек, где дефекты обычно вызывает сочетание двух факторов.

Исследовательское тестирование

Исследовательское тестирование — это одновременное изучение приложения, проектирование и выполнение проверок без заранее написанных кейсов. Чтобы оно не превращалось в «потыкать», его проводят сессиями: ограниченное время (обычно 60–90 минут) и чартер — цель сессии, например «найти способы оформить заказ с некорректной суммой». По итогам сессии фиксируют найденные дефекты и идеи для новых тест-кейсов. Эта техника особенно полезна для новых функций и сложных жестов, которые трудно описать шагами заранее.

Smoke, критический путь, регресс: из чего состоит функциональный прогон

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

1. Smoke-тест. Проверка, что сборка вообще пригодна для тестирования: ставится, запускается, работает вход и главный экран. Проводится на каждой новой сборке, занимает минуты или до часа. Выполняет QA или автотесты в CI.
2. Sanity-тест. Узкая проверка конкретного исправления или изменения: починили расчёт скидки — проверяем расчёт скидки и ближайшие сценарии. Проводится после багфикса, занимает минуты. Выполняет QA.
3. Критический путь. Основные сценарии, без которых приложение теряет смысл: регистрация, вход, поиск, целевое действие, оплата. Проводится на каждой сборке-кандидате, обычно за несколько часов. Выполняет QA, часть сценариев — автотесты.
4. Расширенное тестирование. Все функции с позитивными и негативными сценариями, граничными значениями и разными ролями. Проводится для новых функций и крупных изменений, занимает дни. Выполняет QA.
5. Регрессионное тестирование. Повторный прогон ранее проверенных сценариев, чтобы убедиться, что изменения ничего не сломали. Проводится перед каждым релизом и после рискованных правок. Выполняют QA и автотесты.
6. UAT (приёмочное тестирование). Проверка заказчиком или продактом, что функции решают бизнес-задачу. Проводится перед приёмкой этапа или релиза. Выполняет заказчик, QA готовит сценарии и окружение.

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

Как написать тест-кейс для мобильного приложения

Тест-кейс — это описание одной проверки: что подготовить, какие шаги выполнить и какой результат считать правильным. Хороший тест-кейс может пройти любой член команды, не задавая автору вопросов, и получить однозначный ответ «пройден» или «провален». Для мобильного приложения в нём обязательно указывают окружение, потому что одно и то же действие на разных ОС и устройствах может вести себя по-разному.

Поля тест-кейса:

• ID — уникальный номер для ссылок из баг-репортов и отчётов.
• Название — что проверяем, одной фразой.
• Предусловия — состояние приложения и данных до начала проверки.
• Шаги — короткие действия, по одному на строку.
• Тест-данные — конкретные значения: номер, код, сумма, аккаунт.
• Ожидаемый результат — что должно произойти, проверяемо и без «корректно отработает».
• Окружение — устройство, версия ОС, версия сборки, стенд.
• Приоритет — насколько критична проверка для релиза.

Пример тест-кейса на негативный сценарий входа:

Поле	Значение
ID	AUTH-014
Название	Вход по номеру телефона с неверным кодом из SMS
Предусловия	Приложение установлено, пользователь не авторизован, номер зарегистрирован, на стенде доступно 3 попытки ввода кода
Шаги	1. Открыть приложение. 2. Нажать «Войти». 3. Ввести номер телефона и нажать «Получить код». 4. Ввести неверный код из 4 цифр.
Тест-данные	Номер: тестовый номер стенда; неверный код: 0000
Ожидаемый результат	Под полем появляется сообщение «Неверный код, осталось 2 попытки»; поле очищается; пользователь остаётся на экране ввода кода; вход не выполняется
Окружение	iPhone на актуальной iOS и Android-смартфон среднего сегмента; сборка 2.4.0 (RC1); тестовый стенд
Приоритет	Высокий

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

Правила хорошего тест-кейса:

• Одна проверка — один кейс: не смешивайте вход и оформление заказа.
• Ожидаемый результат конкретен и проверяем: что именно появляется на экране и что не происходит.
• Тест-данные указаны явно, а не «ввести любой номер».
• Кейс не зависит от результата предыдущего, если это не оговорено в предусловиях.
• Формулировки нейтральны к платформе, а отличия iOS и Android вынесены в окружение или отдельные кейсы.
• Кейсы связаны с требованиями: по каждому требованию видно, какими кейсами оно покрыто.

Как провести функциональное тестирование: пошаговый процесс

Процесс функционального тестирования — это семь шагов от анализа требований до отчёта о готовности сборки. В зрелой команде они идут параллельно разработке, а не начинаются после неё: тест-дизайн для функции готов к моменту, когда разработчик отдаёт первую сборку.

1. Анализ требований и рисков. Изучите ТЗ, user story, макеты и критерии приёмки. Составьте список функций и отметьте, где ошибка обойдётся дороже всего: деньги, персональные данные, вход в аккаунт.
2. Тест-план и приоритизация. Зафиксируйте объём проверок, платформы и версии ОС, парк устройств, окружения, критерии начала и окончания тестирования. Разделите функции по приоритету.
3. Тест-дизайн, кейсы и чек-листы. Примените классы эквивалентности, граничные значения, таблицы решений и переходы состояний. Критичные сценарии опишите тест-кейсами, второстепенные — чек-листами.
4. Тест-данные и окружение. Подготовьте тестовые аккаунты под каждую роль, песочницы платежей, стенд с тестовыми данными и сборки через TestFlight или закрытое тестирование Google Play. Учтите, что для новых личных аккаунтов разработчика Google Play требует закрытого теста с минимум 12 тестировщиками, подключёнными не меньше 14 дней подряд, прежде чем открыть доступ к продакшену, — эти две недели стоит заложить в план.
5. Прогон на устройствах. Начните со smoke-теста сборки, затем пройдите критический путь и расширенный набор на реальных iOS- и Android-устройствах из матрицы.
6. Баг-репорты. Для каждого дефекта опишите шаги воспроизведения, ожидаемый и фактический результат, окружение, приложите видео и логи, укажите серьёзность и приоритет.
7. Перепроверка, регресс и отчёт. Проверьте исправления, прогоните регресс затронутых зон и подготовьте отчёт: что проверено, какие дефекты открыты и можно ли принимать сборку.

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

Функциональные отличия iOS и Android, которые ломают сценарии

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

Механизм	iOS	Android	Что проверить
Возврат назад	Свайп от левого края и кнопка в навигации	Системная кнопка или жест «Назад»	Возврат не теряет данные, не закрывает приложение, корректно работает в модальных окнах
Разрешения	Одноразовый запрос: после отказа — только через настройки	Повторные запросы, «только в этот раз», авто-сброс разрешений неиспользуемых приложений	Сценарии отказа, повторного запроса и отзыва доступа
Push-уведомления	APNs, разрешение запрашивается явно	FCM, с Android 13 разрешение на уведомления тоже запрашивается явно	Доставка, отказ от разрешения, открытие нужного экрана
Deep links	Universal Links	App Links	Открытие нужного экрана при установленном и неустановленном приложении
Работа в фоне	Строгие ограничения фоновых задач	Ограничения зависят от версии ОС и оболочки производителя	Завершение загрузок, синхронизация, таймеры, возврат из фона
Встроенные покупки	StoreKit, песочница App Store	Play Billing, тестовые аккаунты лицензирования	Покупка, отмена, восстановление, продление подписки
Бета-раздача	TestFlight	Треки внутреннего, закрытого и открытого тестирования Google Play	Установка тестовой сборки и обновление с неё на релизную

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

Что автоматизировать в функциональном тестировании, а что оставить ручным

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

Критерий	Автоматизировать	Оставить ручным
Стабильность сценария	Функция не меняется несколько спринтов	Новая функция, дизайн и логика ещё меняются
Частота прогона	Каждая сборка или каждый релиз	Разово или редко
Цена поддержки	Простые устойчивые локаторы, предсказуемые данные	Сложные жесты, анимации, камера, биометрия
Тип проверки	Smoke, критический путь, регресс, API	Исследовательское тестирование, оценка удобства, UAT
Данные	Наборы значений для классов эквивалентности и границ	Сценарии, где результат оценивает человек

Порядок, в котором окупается автоматизация: сначала smoke и критический путь, которые запускаются на каждой сборке, затем регресс стабильных функций, параллельно — проверки на уровне API, они быстрее и надёжнее UI-тестов. Инструменты: Espresso для нативного Android, XCUITest для iOS, Appium для кроссплатформенных наборов, Maestro для быстрых декларативных сценариев. Автотесты встраивают в CI: smoke запускается на каждый мердж, регресс — на ночную сборку и сборку-кандидат. Подробнее о выборе стратегии — в статье «Автоматизация тестирования: от выбора стратегии до реализации».

Инструменты для функционального тестирования

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

Задача	Инструменты	Для чего
Управление тестами	TestRail, Qase, TestIT, Allure TestOps	Хранение тест-кейсов и чек-листов, тестовые прогоны, отчёты о покрытии
Трекинг багов	Jira, YouTrack	Баг-репорты, приоритеты, статусы исправления
Прокси и анализ трафика	Charles, Proxyman	Просмотр запросов, подмена ответов сервера, эмуляция ошибок и медленной сети
API	Postman	Проверка API отдельно от интерфейса, подготовка тест-данных
Логи	Android Studio Logcat, Xcode Console	Логи и краши для баг-репортов
Устройства и фермы	Эмуляторы и симуляторы, Firebase Test Lab, BrowserStack	Прогон на разных моделях и версиях ОС без собственного парка
Раздача тестовых сборок	TestFlight, закрытое тестирование Google Play, Firebase App Distribution	Установка сборок тестировщикам и заказчику
Автоматизация	Espresso, XCUITest, Appium, Maestro	Автотесты smoke, критического пути и регресса

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

Частые ошибки при функциональном тестировании

Ошибки функционального тестирования — это пробелы в процессе, из-за которых баги проходят все проверки и попадают к пользователям. Большинство из них видно ещё на этапе тест-плана:

• Проверяют только «счастливый путь». Неверный ввод, отказ в разрешении и обрыв сети остаются без проверки.
• Тестируют только на эмуляторе. Push, камера, биометрия, покупки и фон на реальном устройстве ведут себя иначе.
• Нет тест-данных для ролей и платежей. Сценарии администратора, курьера или подписчика не проверяют, потому что «не было аккаунта».
• Кейсы без ожидаемого результата. Формулировка «проверить вход» не позволяет однозначно сказать, пройден кейс или нет.
• Регресс вручную каждый спринт. Он растёт быстрее команды, и под конец его начинают проходить выборочно.
• Не проверяют обновление со старой версии. Чистая установка работает, а у существующих пользователей пропадают данные.
• Игнорируют повторный запрос разрешений после отказа. Функция молча не работает, и пользователь не понимает почему.
• Требования не уточнены до разработки. Тестировщик и разработчик по-разному понимают одно правило, и спор начинается уже на готовой сборке.

Чек-лист функционального тестирования мобильного приложения

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

• ☐ Установка на чистое устройство и обновление со старой версии без потери данных.
• ☐ Онбординг проходится и пропускается, повторно не показывается.
• ☐ Регистрация и вход: код приходит, истекает, лимит попыток работает.
• ☐ Восстановление доступа, выход, вход с другого устройства.
• ☐ Навигация и «Назад» на обеих платформах не теряют данные.
• ☐ Deep links открывают нужный экран из закрытого и запущенного приложения.
• ☐ Валидация форм, маски и типы клавиатур.
• ☐ Черновики сохраняются при сворачивании, звонке и повороте экрана.
• ☐ Расчёты цен, скидок, промокодов и доставки, включая их сочетания.
• ☐ Роли и права: каждый видит только своё.
• ☐ Оплата: успех, отказ, отмена, таймаут, нет двойного списания.
• ☐ Встроенные покупки и восстановление покупок в песочнице.
• ☐ Push приходит и открывает нужный экран из трёх состояний приложения.
• ☐ Разрешения: выдача, отказ, «только один раз», отзыв в настройках.
• ☐ Офлайн: понятное состояние, очередь действий, синхронизация без дублей.
• ☐ Ошибки API 4xx и 5xx показываются понятным сообщением.
• ☐ Истёкший токен не теряет данные пользователя.
• ☐ Пустые состояния и максимальная длина полей.

Это только функциональная часть. Решение о выпуске включает ещё производительность, безопасность, совместимость и требования сторов — для этого используйте чек-лист тестирования мобильного приложения перед релизом. Если сборка с явными багами всё же уйдёт на ревью, Apple отклонит её по пункту 2.1 App Completeness правил App Review: в 2024 году, по данным App Store Transparency Report, 1 235 471 из 1 931 400 отклонений пришлись на категорию Performance, куда входят краши и явные баги.

Частые вопросы о функциональном тестировании мобильных приложений

Чем функциональное тестирование отличается от регрессионного?

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

Можно ли проводить функциональное тестирование только на эмуляторах?

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

Сколько времени занимает функциональное тестирование мобильного приложения?

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

Кто пишет тест-кейсы: разработчик или тестировщик?

Функциональные тест-кейсы пишет QA-инженер по требованиям, user story и критериям приёмки. Разработчик отвечает за модульные тесты своего кода, а аналитик или продакт — за то, чтобы требования были проверяемыми. Хорошая практика — согласовать ключевые кейсы с продактом до начала разработки функции.

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

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

Какие функции проверять в первую очередь, если сроки горят?

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