ТЕСТИРОВАНИЕ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ — ОСОБЕННОСТИ ПРОЦЕССА

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

Мы работаем со множеством платформ, но давайте поговорим именно о тестировании мобильных приложений. Речь пойдет о том, что все так любят и часто используют — смартфоны и планшеты. Без них сложно представить нашу жизнь и ведение бизнеса, сегодня приложение вашей компании, которое доступно в App Store и Play Market — чуть ли не обязательное условие для большинства бизнес-проектов. А раз есть спрос, то будет и предложение.

Разработка мобильного приложения отличается от других типов проектов, например, создания веб-сайта или CRM. Отличен будет как стек технологий, так и подход к дизайну (UI/UX, кстати, тоже тестируется!). И, конечно, существуют особенности тестирования мобильных приложений. Разберем наиболее интересные из них.

Прежде всего мы учитываем особенности тестирования каждой платформы: iOS и Android, а также их версию. Есть и другие ОС, но эти две — самые распространенные. Приложение может разрабатываться на обе платформы одновременно, но особенности ОС будут влиять и на разработку, и на тестирование. В зависимости от ОС и её версии может отличаться поведение приложения. Например, такое можно заметить, если сравнить выделение смс-сообщений в iOS 12 и iOS 14: на 12-й выделение происходит с простым появлением выпадающего меню, тогда как на 14-й версии появился новый компонент contextMenuIntegration, при использовании которого отрисовывается красивая анимация с замыливанием фона, когда само сообщение остается в фокусе.

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

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

Нельзя забывать и про те аспекты, которые делают ваш смартфон «мобильным» — сотовая связь и Wi-Fi. Если приложение по своему функционалу требует подключения к интернету, придется тестировать его работу в условиях подключения к мобильному интернету или Wi-Fi. Сами по себе они не создают проблем: соединение есть — и, например, приложение может общаться с сервером. Но частные случаи здесь возникают ровно тогда, когда Wi-Fi и интернет на сотовой сети начинают взаимодействовать вместе: всегда следует проверять, как ваше приложение работает, если в процессе его использования было переподключение с Wi-Fi на сотовую связь: некоторые технологии требуют, чтобы этот случай был обработан отдельно, а иначе этот кейс некорректно отработает. Например, вы были в кафе, где использовали местную Wi-Fi сеть, но через некоторое время спешно вышли на улицу с телефоном в руках. Допустим, вы разговариваете с мамой по видеосвязи — и вдруг, когда вы отошли на некоторое расстояние от заведения, у вас все прерывается и звонок не может восстановиться. Виной тому будет как раз необработанный кейс с переключением с Wi-Fi на LTE.

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

В ручном тестировании есть свои инструменты, которые упрощают жизнь тестировщикам. Это и такие системы управления тестами, как TestLink, и эмуляторы мобильных устройств, и различные подходы (как чек-лист, например). Но отдельно стоит рассказать про инструменты тестирования API, такие как Postman и Firecamp, а также про снифферы для мониторинга трафика Charles и Fiddler.

Начнем с API. Когда мы говорим о приложении, которое нуждается еще и в хранении каких-то данных на сервере, мы подразумеваем не только его клиентскую часть — непосредственно устройство (приложение, если точнее), но еще и сервер. То, как сервер общается с клиентом, тоже должно быть протестировано. И здесь нам приходит на помощь такой инструмент, как Postman — очень популярный атрибут тестировщика. Он позволяет создавать запросы на сервер, отслеживать ответы, даже создавать коллекции для автоматизации этого процесса. И это всё — не прибегая к использованию смартфона!

Но иногда при тестировании API не обойтись без использования смартфона. Например, когда именно на смартфоне генерируются уникальные данные (например, токен авторизации), которые не получится сгенерировать другими способами. И в такой ситуации нам нужно знать, как нам отвечает сервер. Для этого пригодятся снифферы — Charles и Fiddler. Если трафик с телефона проксировать через ПК, то сниффер позволяет мониторить запросы с клиента на сервер и ответы с сервера на клиент. Таким образом можно узнать, как ответил сервер на попытку авторизации или на какой-нибудь другой функционал. И более того, Fiddler позволяет даже эмулировать ответ с сервера — чтобы посмотреть, как клиент реагирует на тот или иной ответ. Это сильно облегчает жизнь тестировщику, когда приходит время тестировать бэкенд.

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

Баг серьезный, и на него следует завести отдельную задачу. Но сначала нужно разобраться, на чьей стороне проблема: на сервере (Backend) или на клиенте (iOS или Android). Необходимо это для того, чтобы нужный разработчик взялся за решение этой проблемы.

Если баг визуальный, то скорее всего вопрос к платформе-клиенту, тестирование верстки приложения — довольно частый кейс. Но баг может быть связан с логическим поведением приложения. Здесь поможет либо простой анализ поведения с учетом знаний архитектуры приложения, либо Fiddler или Charles, который позволяет понять: это сервер неправильно реагирует на корректный запрос клиента, или клиент некорректно отреагировал на ответ сервера? Разобравшись с этим, с полной уверенностью можно заводить задачу нужному отделу — по всем правилам заведения хорошего багрепорта, конечно же. С понятным названием, полным описанием, окружением, шагами, фактическим/ожидаемым результатом и по возможности скриншотами или видео.

Разобрались с интересными особенностями и этапами тестирования мобильной платформы, а чем же это полезно? Как тестирование делает ваш продукт лучше, помимо того, что тестировщик находит и локализует дефекты, которые будут исправлены? Ответ довольно прост: цена. Чем раньше будет найдена проблема, тем дешевле обойдется ее решение: баг, найденный на стадии релиза, может потребовать гораздо больше времени (читай — денег) для фикса, чем тот, что нашли на первых стадиях разработки.

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

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

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

И да пребудет с вами качество!