Home

Автор: Даниил Майстренко, Perfomance Lab

Оригинальная публикация

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

Специфика проекта

• Данный проект был международным и распределенным территориально. Все коммуникации, процессы и артефакты были на английском языке. В проекте участвовали команды из Индии, центральной России, Москвы и Эль–Сальвадора, главный офис заказчика – в Калифорнии.
• Мы занимались тестированием приложения, написанного для конкретного фитнес-девайса: приложение нельзя было просто скачать из магазина и приступить к работе. Также требовалось уделить особое внимание взаимодействию девайса с телефоном и приложением.
• Наше общение с Заказчиком началось с того, что они не смогли самостоятельно пройти предрелизные проверки для добавления своего приложения в AppStore и Google Play. Как следствие, для начала нам потребовалось провести тестирование по гайдлайнам от Apple и Google.
• Как это нередко бывает в мобильной разработке, iOS версия опережала на пару спринтов Android и все новые фичи сначала появлялись для IOS.
• На старте проекта не было документации, и она появлялась только на новые фичи.

О самом устройстве и приложении

Рисунок 1 — Фитнес-девайс

Фитнес-девайс выглядит как небольшой «камешек» с датчиком, который считывает давление на стенки устройства, Bluetooth модулем для передачи этих данных, батарейкой и LED- индикатором состояния.

После запуска приложения необходимо авторизоваться и включить фитнес-девайс. Приложение сканирует все Bluetooth-устройства вокруг и позволяет соединить девайс с телефоном. Приложение включает набор упражнений, представленных в виде кривых с чек-поинтами. Для их выполнения необходимо занять указанную в упражнении позицию и давить на девайс. Чем сильнее давление – тем выше идет курсор и наоборот. Варьируя давление и напрягая/расслабляя мышцы, мы имитируем работу в зале. Перед выполнением упражнения девайс необходимо откалибровать, приложив максимальное усилие в данной позе для того, чтобы задать верхнюю границу. Упражнения разделены по воркаутам либо по группам мышц, которые вы хотите накачать. Ниже, на изображениях 2-6, показаны скриншоты приложения во время работы.

Рисунки 2 — 6 — скриншоты приложения

Рисунок 7 — Схема взаимодействий

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

• Одной из главных особенностей мобильного тестирования является необходимость испытаний на большом количестве конфигураций устройств, так как на каждой отдельной модели телефона приложение может повести себя по-разному. Дефекты, появляющиеся на конкретных устройствах, являются девайсо-зависимыми. Их причина может быть в версии ОС, взаимодействии с прошивкой производителя, нестандартном разрешении экрана или его пиксельной плотности, версиях Bluetooth и т.д.
• Поскольку зачастую в мобильных приложениях нет очень громоздкого функционала, тестовую модель лучше писать в виде множества простых тестов. Таким образом, вы получите более наглядную и простую картину тестирования, нежели при наличии объемных тестов, включающих в себя множество проверок. Также ее будет проще править при изменении требований.
• Зачастую мобильные приложения требуют взаимодействия с телефоном через Bluetooth (носимая электроника, фитнес-девайсы), NFC (сканирование, оплата), геолокацию (карты). Необходимо уделить особое внимание тестированию подобных взаимодействий.
• Важно не забывать тестировать приложение на прерывания (приходящие смс, звонки, подключение к зарядному устройству, низкий заряд аккумуляторов, смену ориентации экрана), а также на границах действия Bluetooth, в условиях слабого сигнала сети и т.п.
• Мобильное тестирование может быть действительно «мобильным»: вы можете быть не только не привязаны к вашему рабочему месту, но и вам, возможно, придется бегать, прыгать с этим устройством, или ходить с ним по городу и проверять работу приложения в полевых условиях.

Список мобильных устройств

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

Парк устройств необходимо выбирать в зависимости от рынка, на который выпускается ваш продукт, его системных требований и бюджета проекта. Покрыть 100% рынка невозможно и даже приближение к данной цифре нерационально – это сотни устройств. Если брать для примера американский рынок, то большую его часть составят устройства Apple и Samsung. 15 устройств покрывают порядка 30% рынка, 50% покрытия — уже более 40 устройств. В России же спектр телефонов гораздо шире из-за огромного количества разнообразных китайских андроидов и немалой доли старых моделей. Доля каждого следующего устройства становится все меньше и собирать парк становится сложнее. Поэтому количество устройств на проекте во многом упирается в бюджет, который вы готовы выделить, так как наибольшую часть дефектов можно будет обнаружить уже при покрытии порядка 30%. Для выбора парка устройств вы можете воспользоваться сайтом perfecto mobile для просмотра общих данных по региону либо, если у вас есть подобная возможность, аналитикой по использованию вашего приложения (к примеру Google Analytics).

Таблица 1 — Список устройств на проекте на момент старта

Также важно учитывать минимальные требования вашего приложения, к примеру, в данном примере приложение поддерживало версии Android начиная от 4.4.4. и iOS от 9й. Дополнительно необходимо было, чтобы устройство имело Bluetooth стандарта 4.0 (то есть на старых iPad приложение не могло обнаружить сам фитнес-девайс).

Требования Google и Apple к релизу

Перед тем как попасть в Google Play и AppStore, все приложения должны пройти первоначальную проверку от магазина на соответствие стандартам (гайдлайнам). Требования Google достаточно мягкие, что зачастую приводит к захламленности Google Play кучей низкокачественных и просто спорных приложений. У Apple же гораздо более жесткие критерии соответствия для приложений, описание которых занимает ни одну страницу. Среди причин, по которым данное приложение было отклонено до начала нашей совместной работы было то, что оно «крашилось» в сетях ipv6 only.

Если тестируемое вами приложение еще не было добавлено в магазины, его необходимо самостоятельно протестировать на соответствие гайдланам. Самостоятельная проверка позволит сэкономить время (проверка магазином занимает обычно 3 дня) в случае, если будет выявлено несоответствие и выкладка будет отменена. Ссылки на требования: Google Play и AppStore.

Инструменты тестирования

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

• Trello – известный многим симулятор пасьянса, в котором удобно держать карточки задач на небольшом проекте.
• Lean Testing – бесплатный багтрекер + хранилище тестовой модели.
• Charles Proxy – сниффер трафика, для чтения HTTP/HTTPS запросов.
• Xcode – сбор логов с iOS.
• Android Studio – снятие логов c Android.
• Appium – проект мы начинали как ручное тестирование, автоматизация добавлялась уже на следующих этапах с его помощью.
  

Выбор тестов для автоматизации

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

Для начала мы разделили тесты на 3 группы по взаимодействию с устройством:

• User UI/UX actions only – тесты, для выполнения которых достаточно только автоматизации действий пользователя.
• Simulated device inputs + User UI/UX – где кроме действий пользователя необходимо эмулировать данные с девайса.
• Real Activ5 device + User UI/UX actions — тесты, для выполнения которых необходимо использовать настоящий девайс.

Также мы разделили тесты на 3 группы по подходу к автоматизации:

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