Постоянный автор нашего блога, Senior QA Engineer и QA Division manager Noveo Анастасия рассказывает о codeless-инструментах автоматизации тестирования.

Всем привет! Меня зовут Настя, и недавно я посетила конференцию SQA days 27 в Минске, где выступила с докладом о том, какой может быть автоматизация, если вы не хотите или не имеете возможности учиться писать код.

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

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

В идеальном мире VS в реальности

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

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

В идеальном случае активности по построению системы автотестов планируются и готовятся заранее. Ещё в идеальной ситуации весь код покрыт юнит- и интеграционными тестами, все эндпоинты API — сервисными тестами, а GUI-тесты проверяют конечные сценарии и вёрстку (спасибо, скриншотеры!). Там же все помнят про пирамиду тестирования, и, скорее всего, у нас есть один или несколько наставников, готовых передать знания по инструментам и подходам.

Но самое главное: в идеальном мире мы уже умеем писать код к моменту, когда решили использовать автотесты в работе.

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

• многие (или все) тестировщики в команде не умеют писать код, и в данный момент нет ни времени, ни «свободного» эксперта для их обучения;
• необходимо внедрять автоматизацию как можно скорее;
• неизвестно, будет ли необходимость поддерживать эти автотесты и, соответственно, имеет ли смысл инвестировать в их создание и настройку много времени и сил.

Привет, нам срочно нужны автотесты!

Я часто посещаю (а иногда и помогаю организовать) встречи, мероприятия и митапы, на которых мы говорим о насущных проблемах QA-инженеров. Увы, но опыт показывает, что ситуация и трудности, описанные выше, случаются чаще, чем того бы хотелось, а универсального решения, разумеется, нет. Значит, с каждой проблемой надо работать отдельно; но с какой стороны зайти?

Итак, к нам поступил запрос на внедрение автоматизации в проект. Один из хороших вариантов — начать с самого простого шага: задать необходимые вопросы.

1. Цель:
   1. Зачем нам нужны автотесты? Для чего?
   2. Есть ли какая-то картина того, что ожидается?
2. Текущие условия:
   1. Автоматизированных тестов бывает много: unit, API, GUI, e2e… Что уже есть у нас?
   2. Тестировщики совсем не понимают код, или какие-то базовые навыки есть?
   3. Какая вообще ситуация с автотестированием на проекте? В компании?
   4. Каковы сроки проекта?
   5. Каков размер команды (и QA, и разработчиков)?
   6. Насколько детальное требуется покрытие?
   7. Нужно ли добавлять тесты к процессам CI?
   8. Будет ли потом поддержка проекта? Тестов?
   9. Есть ли какой-то бюджет на инструменты для тестирования?
   10. Какие требования к окружению?

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

Если же ситуация печальная, — автотесты нужны были ещё вчера, менторов нет, людей мало, а проект нестабильный и короткий, — то можно попробовать прибегнуть к помощи утилит, называемых codeless-инструменты автоматизации тестирования.

Codeless-инструменты — такие утилиты, которые позволяют нам создавать, изменять и прогонять автотесты без написания кода (как следует из их названия). Как правило, они представляют из себя т.н. рекордеры — инструменты для записи действий пользователя, впоследствии эти действия воспроизводящие.

Выглядит это примерно так:

Как и любой инструмент, codeless-ы имеют свои границы применения. Они могут быть полезны, когда:

• мало человек в команде умеет писать код, а времени учиться нет;
• надо быстро написать много тестов на простую систему;
• тесты не требуют поддержки в долгосрочной перспективе;
• компания использует определённую утилиту по умолчанию;
• нужно наглядно продемонстрировать, как работает автоматизация UI-тестирования (как вариант, в качестве игрушки на “пощупать” для совсем начинающих тестировщиков);
• вам просто нравится инструмент, а время и специфика позволяют использовать именно его.

Кроме того, принять решение об использовании таких инструментов проще, если вы знаете как их плюсы, так и их недостатки:

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

• Selenium IDE
• Katalon automation recorder
• Katalon Studio
• Testim
• Ranorex Studio
• Mabl
• TestProject

Разумеется, чтобы сравнение было более-менее объективным, нам нужны четкие критерии. В данном случае я выбрала такие параметры, как:

• бесплатный /платный;
• уровень покрытия: UI / UI+API;
• web-версия / десктоп-клиент;
• платформы: web / мобилки / desktop;
• возможность шарить тесты;
• возможность экспортировать тесты в код;
• возможности работы с тестами;
• open source / коммерческое.

Давайте же сами посмотрим, что может дать нам каждый из выбранных инструментов.

Сравним наши возможности

Полное сравнение по критериям заняло довольно много место и растянуло бы этот пост ещё на 10 страниц, поэтому со сводной таблицей сравнения по упомянутым критериям предлагаю вам познакомиться самостоятельно по ссылке. Здесь же хотелось бы обобщить и сравнить интересные особенности каждого из рекордеров.

Что же выбрать?

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

• Самый доступный: Selenium IDE
• Самый многофункциональный: Ranorex Studio / Katalon Studio / Testim
• Самый популярный: Selenium IDE
• Самый кастомизируемый: TestProject
• Самый подходящий для коротких проектов: TestProject
• Самый подходящий для долгих, больших проектов: Katalon Studio / Ranorex Studio / Testim
• Самый простой для «входа» в кодинг: Katalon Studio

Впрочем, вы и сами можете организовать сравнение и выбрать свой вариант. Для этого можно воспользоваться таким алгоритмом:

1. Определяем критерии выбора:
   1. Задаем вопросы;
   2. Формулируем критерии (или берем готовые);
   3. Приоритезируем их, учитывая текущую ситуацию;
2. Проводим сравнение:
   1. Учитываем критерии;
   2. Не забываем про здравый смысл;
   3. Согласуем с руководством и командой;
3. Мотивация:
   1. Всегда помним, ЗАЧЕМ мы это делаем!

Подведем итоги

Codeless-инструменты — это, как правило, обёртка над возможностями Selenium Webdriver. Они хороши для срочных проектов, исключительных ситуаций или на начальном уровне карьеры тестировщика, но если вы хотите углубляться в автотесты — придётся учиться писать код, использовать тестовые фреймворки и познавать все прелести автоматизации.

Тем не менее, чем бы вы ни пользовались, всё в первую очередь зависит от вас и вашего подхода к решению задач: будь то codeless-утилиты или тестовые библиотеки, надо помнить, что автоматизация тестирования — всё ещё просто инструмент, а значит, именно в руках умелого мастера она принесет максимум пользы. Дорогу осилит идущий!

Для тех, кто хочет всё попробовать сам:

• Selenium IDE — https://clck.ru/JZUNm
• Katalon automation recorder — https://clck.ru/JZUTr
• Katalon Studio — https://clck.ru/JZUXJ
• Testim.io — https://testim.io/
• Ranorex Studio — https://clck.ru/JZUYt
• Mabl — https://www.mabl.com
• TestProject.io — https://testproject.io
• Testcraft.io — https://www.testcraft.io