Автор: Мирза Зизик (Mirza Sisic)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я расскажу о первых впечатлениях и опыте использования инструмента low-code для автоматизации UI-тестов. Если вы незнакомы с термином «инструменты для автоматизации тестирования с низким порогом кода (low-code)», это визуальные инструменты, позволяющие пользователям автоматизировать тесты с минимальными или нулевыми знаниями программирования.

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

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

Наш контекст тестирования

Нам понадобился low-code инструмент для тестирования нашего нового бухгалтерского приложения. Это приложение работает с большим количеством различных налоговых кодов, каждый из которых соответствует определённому проценту. Если эти проценты рассчитываются некорректно, НДС будет неверным — как и бухгалтерские проводки.

Поэтому нам нужно было уметь комбинировать множество разных наборов параметров в тестах (техника, известная как комбинаторное тестирование) и минимизировать повторение любых наборов комбинаций.

Мы попробовали несколько инструментов от разных вендоров, таких как Katalon, Ranorex, Virtuoso, Testim, testRigor, ACCELQ и Leapwork.

Развенчиваем мифы о low-code инструментах для автоматизации тестирования

Надёжность тестов

Многие утверждают, что тесты, созданные с помощью low-code инструментов, менее надёжны, чем те, что написаны на Selenium, Cypress, Playwright и т. д. Когда такие инструменты только появились на рынке, это действительно было так. Однако со временем они значительно улучшились и стали проще в использовании.

ИИ-возможности? Ну… частично.

Многие инструменты рекламируют себя как «на основе ИИ». К этому стоит относиться скептически.

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

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

Первые впечатления: несколько приятных сюрпризов

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

Богатый набор функций

Попробовав один из таких инструментов впервые, я был удивлен тем, насколько он функционален. Можно было:

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

Хорошая поддержка со стороны вендора

Онбординг для новых клиентов

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

Выделенная техподдержка

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

Проблемы, с которыми мы столкнулись при использовании low-code инструментов автоматизации тестирования

Как уже упоминалось, у low-code инструментов есть свои недостатки, поэтому перед выбором решения необходимо провести исследование и протестировать множество продуктов.

Мы столкнулись с крупными и мелкими проблемами:

• Мы могли создавать ярлыки (labels) для тестов, но не могли их потом редактировать (поставщик это исправил).
• При подключении сторонней библиотеки ассертов npm производительность резко падала (поставщик тоже исправил это через пару дней после отправки тикета).
• Возможности отладки минимальны: можно ставить брейкпоинты — и это почти всё.
• Проблема вендор-lock-in: у одного инструмента функциональность веб-тестирования была отличной, но мобильное тестирование сильно отставало. Если бы мы продолжили использовать этот инструмент, пришлось бы брать ещё один инструмент другого вендора в дополнение или вместо него.

Непрозрачность ценообразования

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

Во многих случаях, чтобы узнать цену, нужно общаться с менеджером по продажам.

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

Отладка результатов «чёрных ящиков»

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

По сути, визуальная отладка ограничена, потому что нет доступа к внутренним механизмам инструмента – в отличие от работы с собственным фреймворком на Selenium и JUnit, например.

Ограничения при работе с несколькими вкладками браузера

Я часто сталкивался с проблемами, если тесты должны были открывать новые вкладки или работать с несколькими вкладками одновременно. Это было слабым местом во всех инструментах record-and-playback, которые я пробовал.

Что происходило: я записывал тест, который открывает страницу в новой вкладке. Несколько запусков всё работало — а потом начинались случайные падения. Поскольку вы ограничены только теми способами отладки, которые предлагает инструмент, ваш максимум — поставить брейкпоинты на записанные шаги. Это довольно примитивный подход к дебагу.

Особенность: запуск тестов в облаке вендора

У некоторых инструментов тесты в облаке вендора не запускались, пока мы не внесли IP-адреса наших тестовых окружений в белый список.

Нелепые ограничения на создание и удаление шагов теста

В одном из инструментов было невозможно удалить общие шаги. Даже если ни один тест их не использовал, их можно было только скрыть, но не удалить. Логики в этом было мало.

Посредственная производительность и ограниченный контроль тест-плеера

Иногда тест-плееры работали медленно, хотя некоторые проблемы вендор смог исправить. Помимо этого, мы не всегда могли настроить плеер так, чтобы пропускать тесты. Максимум — поместить их в карантин.

Насколько эти инструменты на самом деле «low-code»? Только до определённого уровня

Все эти инструменты обещают, что ими можно пользоваться без навыков программирования. Но на практике любая чуть более сложная настройка требует писать код. Например, иногда инструмент не позволял указать нужный DOM-элемент, и приходилось писать кастомный JavaScript. То есть «low-code» они до тех пор, пока вы не выходите за пределы базового сценария.

Заключение

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

• Документация
• Удобство использования, локально и через веб
• Возможности кастомизации
• Возможности параметризации
• Цена

В итоге мы выбрали инструмент с самым высоким общим баллом.

Коммерческие low-code инструменты для автоматизации тестирования значительно эволюционировали, особенно за последнее десятилетие. Они становятся всё более удобными, позволяют быстро создавать тесты, сокращают время разработки и помогают улучшить взаимодействие между командами. Для более простых сценариев UI-тестирования такие инструменты могут экономить огромное количество времени.

• Интеграция с другими инструментами. Поскольку эти решения активно развиваются, теперь доступно множество вариантов интеграции с другими платформами. Например, при падении теста может автоматически создаваться баг в Jira, тест-раннер может отправлять сообщение в Slack после завершения прогона, и так далее.
• Поддержка тестов. Поддерживать тесты, созданные инструментами record-and-playback, стало проще, но всё ещё более рутинно и затратно по времени, чем в случае кастомных фреймворков.
• Ограниченная гибкость, масштабируемость и возможности кастомизации. К минусам можно отнести ограниченную гибкость и возможности настройки, особенно если ваши задачи по автоматизации сложные и требовательные. Вы также можете столкнуться с трудностями масштабирования. По мере роста количества и сложности тестов увеличивается длительность их поддержки и выполнения.
• Мои рекомендации по оптимальному использованию low-code инструментов. С относительно простыми (особенно веб) приложениями многие из этих инструментов справляются очень достойно. В конечном счёте вам нужно внимательно проанализировать свои потребности в автоматизации, попробовать несколько low-code решений и выбрать то, которое лучше всего подходит именно вам.