Автор: Нихил Дабаде (Nikhil Dabhade)
Оригинал статьи
Перевод: Ольга Алифанова

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

«Какой фреймворк тест-автоматизации выбрать для автоматизации мобильных и веб-тестов?»

Стоит ли выбрать Espresso (для Android) и XCUI (для iOS), или же решиться на что-то вроде Appium (кросс-платформенный инструмент)? Что успешно применяют другие? Какой фреймворк в долгосрочной перспективе меньше расшатывается? Есть ли какие-то преимущества, гарантированные при использовании определенного фреймворка? Буду ли я привязан к нему после выбора?

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

Структура команды

Структура команды в этом контексте может принадлежать к одному из двух типов. А) Команды, у которых есть мобильные разработчики, также отвечающие за тестирование – включая юнит-тесты, функциональные, UI и интеграционные тесты. Б) Команды, в которых есть специалисты-тестировщики, чья основная задача – убедиться в качестве приложения с точки зрения функциональности, пользовательского интерфейса и производительности.

Команды первого типа, где разработчики пишут как приложение, так и UI-тесты, часто придерживаются своих привычных инструментов. К примеру, iOS-разработчику комфортно писать на Swift в экосистеме iOS. Следовательно, фреймворк UI-тестирования вроде XCUI естественным образом ему подойдет. Android-разработчик, в свою очередь, скорее выберет Espresso-тесты на основе Kotlin. Известное окружение, скорость запуска и простота поддержки репозитория тестов позволяет быстрее работать и добиваться нужных результатов. В большинстве случаев разработчики iOS и Android – это разные люди, если они разрабатывают нативные приложения и не пользуются кросс-платформенным фреймворком вроде React Native или Ionic.

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

Скорость запуска

Скорость команд, пользующихся знакомыми инструментами, выше, а кривая обучения практически отсутствует. В случае команд, использующих кросс-платформу, скорость может быть и такой же – это зависит от степени их знакомства с фреймворком. Кривая обучения для этих команд высока на старте, но по мере ознакомления с фреймворком они, возможно, опередят первую группу, так как пишут тесты для обеих экосистем. Это, конечно, если предположить, что разработчик приложения правильно и последовательно применял ID элементов. Рассогласованные ID или их отсутствие замедлит QA-команду, заставляя ее использовать методы вроде xpath, не рекомендуемые Appium.

Поддержка

Поддержка в этом случае – дело субъективное. Скажем, если взять в качестве примера Appium-подход, когда база кода для тестов едина, вам может понадобиться только одно окружение для запуска как iOS, так и Android-тестов. С другой стороны, тесты в той же базе кода, что и приложение, конечно, просто поддерживать, но выполнение тестов для обеих экосистем может потребовать разных окружений. К примеру, XCUI-требуют Mac. Я также знаю, что iOS-тесты Appium лучше запускаются на Mac. Отсюда и берется субъективность.

Широта покрытия типов тестирования

Широта в этом контексте – это типы тестов: интеграционные, производительности, и т. д. Использование инструментов экосистем часто служит универсальным механизмом для всех типов тестов, а команды с кросс-платформенными инструментами зачастую пользуются дополнительными решениями для тестирования производительности.

Глубина тестов

Глубина в этом случае относится к типу и количеству UI-потоков, которые вы можете разработать. К примеру, если вы хотите выключить WiFi или открыть просмотр настроек в нативном мобильном приложении, то для этого у нативных тест-фреймворков вроде XCUI и Espresso есть простой, рабочий API. У кросс-платформенных фреймворков он тоже есть, но зачастую надстроен над родными API и может не совпадать для всех версий ОС. В большинстве сценариев тут преимущество за нативными тест-фреймворками экосистем.

Заключение

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

Обсудить в форуме