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

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

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

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

Из-за этого даже привычный сценарий авторизации может вести себя совершенно по-разному в зависимости от модели телефона, версии операционной системы или состояния сети.

• Представим обычное приложение интернет-банка.

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

Но тестировщик почти автоматически начинает задавать дополнительные вопросы:

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

Получается, что одна задача постепенно превращается в целую серию различных проверок.

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

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

Одной из самых сложных особенностей Mobile Testing считается огромное количество устройств.

Даже если говорить только об Android, приложение должно одинаково корректно работать на смартфонах Samsung, Xiaomi, Google Pixel, OnePlus, Honor и десятках других производителей. При этом отличаются не только размеры экранов, но и фирменные оболочки, объем оперативной памяти, версии Android и особенности реализации некоторых системных функций.

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

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

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

В отличие от веб-сайта мобильное приложение постоянно меняет свое состояние.

—> Пользователь может открыть камеру, ответить на звонок, переключиться в мессенджер, подключить Bluetooth-наушники или просто свернуть приложение на несколько минут.
После возвращения он ожидает увидеть именно то место, на котором остановился.

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

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

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

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

Что стоит проверить в первую очередь

• Пользователь отказал в доступе к камере.
• Геолокация отключена.
• Разрешение сначала отклонили, а затем выдали.
• Пользователь запретил push-уведомления.
• Разрешение было отозвано уже после установки приложения.

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

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

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

Поэтому тестировщик намеренно создает нестандартные условия: включает авиарежим, замедляет скорость сети, переключается между Wi-Fi и LTE или полностью отключает интернет в самый неподходящий момент.

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

Представим ситуацию:
пользователь жалуется, что баланс счета отображается неверно. Виноват ли интерфейс?
Не всегда.

Опытный QA сначала проверит сетевые запросы. Возможно, сервер уже вернул неправильное значение, а приложение лишь корректно его отобразило. А может быть, API работает идеально, а ошибка возникла уже при обработке данных на стороне клиента.

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

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

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

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

Иногда именно такие наблюдения становятся первым сигналом о серьезной технической проблеме.

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

Начинающему специалисту стоит разбираться в особенностях Android и iOS, понимать жизненный цикл мобильного приложения, знать основы работы HTTP и REST API, уверенно пользоваться инструментами анализа сетевого трафика, понимать принципы клиент-серверного взаимодействия и уметь воспроизводить нестандартные пользовательские сценарии.

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


Хотите узнать больше? Изучите другие статьи из раздела:

• Основы и старт в IT