Всем привет! Меня зовут Ксюша, и я тестирую мобильные приложения в компании ATI.SU

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

Начнем с девайсов

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

Как же учесть это, ведь невозможно протестировать приложение на всех вариантах устройств? Стоит выбирать наиболее популярные среди ваших пользователей девайсы, а еще тестировать на самой старой и самой новой из поддерживаемых ОС. Также важно проверять приложение девайсах с сильно кастомизированными прошивками. Например, xiaomi, huawei, samsung.

Перейдем к ui и ux

Для каждой из платформ существуют гайдлайны: Google Material Design для Android и Human Interface Guidlines для ios. В гайдлайнах описаны элементы интерфейса, их размеры, расположение на экране и не только. Гайдлайны нужны, чтобы создавать такой дизайн, который позволит пользователю не думать над простыми действиями. Например, над навигацией или выбором элементов. А еще гайдлайны пригодятся, чтобы один и тот же дизайн был одинаково функционален на разных девайсах и разных версиях платформы. Хорошее приложение должно следовать гайдлайнам, а тестировщик проверить это.

Кроме требований гайдлайнов, важно тестировать то, как пользователь взаимодействует с девайсом. Он может изменить размер шрифта, повернуть экран в ландшафтную ориентацию или свернуть приложение.

Рассмотрим разрешения

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

Потестируем запросы

Приложение - это в первую очередь про фронтенд. Для взаимодействия с бекендом оно использует http-запросы. Запросы, как известно, могут возвращать разные коды ответа. Например, 400, 500 и другие. А также ответы могут приходить с таймаутом. Тут важно протестировать реакцию приложения на различные коды ответа, таймауты разной длины и измененное body ответа. Для тестирования подобных ситуаций используются снифферы - инструменты для перехвата трафика и подмены запросов и ответов. Снифферы позволяют изменять запрос и ответ целиком или частично. Самые популярные - это Charles и Fiddler. О работе с ними я постараюсь рассказать подробнее в отдельной статье.

Обновим приложение

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

Используем функции девайса

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

Давайте зарелизим

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

Когда билд готов к релизу, его загружают в Play Market или App Store. Там приложение проходит ревью и становится доступным для скачивания. Однако пользователи получат новый релиз только когда обновятся. А это процесс не быстрый. У большинства пользователей может быть отключено автообновление, и они могут месяцами откладывать обновление вручную.

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

Подытожим

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

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