Постоянный автор нашего блога, Senior QA Engineer и QA Division manager Noveo Анастасия рассказывает о codeless-инструментах автоматизации тестирования.
Всем привет! Меня зовут Настя, и недавно я посетила конференцию SQA days 27 в Минске, где выступила с докладом о том, какой может быть автоматизация, если вы не хотите или не имеете возможности учиться писать код.
На мой взгляд, знание разных возможностей и инструментов работы и границ их применения — плюс для специалиста любого уровня. Тем не менее, перед конференцией я очень волновалась, т.к. неоднократно сталкивалась с мнением, что codeless-автоматизация — нечто бесполезное и ненужное. В итоге все прошло хорошо, и волнение было напрасным: оказалось, к codeless-инструментам прибегает больше людей, чем я думала.
Поэтому мне бы хотелось поделиться проведенным сравнением и здесь: возможно, кому-то эта подборка пригодится для работы, а кому-то — просто для общего развития и интереса к возможностям существующих инструментов.
В идеальном мире VS в реальности
Давайте вспомним, что же такое автоматизация. Для меня это инструмент работы: мощный, классный и удобный, однако требующий четкого понимания, зачем и когда он применяется, а также рук умелого мастера.
Мне нравится сравнение автоматизации с молотком: он идеален, чтобы забить гвоздь, и несомненно нужен в хозяйстве, но если нам надо поделить одну длинную доску на две коротких, мы скорее выберем пилу. Конечно, мы можем попробовать разбить доску пополам молотком, если обеспечим ей положение с фиксированными краями, но без опоры в центре. Однако линия распила — вернее, в данном случае, разлома — будет неровной, а усилий мы потратим в разы больше, чем если бы использовали подходящий инструмент… В общем, думаю, мы все поняли метафору: автоматизация тестирования должна применяться вовремя, грамотно и обоснованно.
В идеальном случае активности по построению системы автотестов планируются и готовятся заранее. Ещё в идеальной ситуации весь код покрыт юнит- и интеграционными тестами, все эндпоинты API — сервисными тестами, а GUI-тесты проверяют конечные сценарии и вёрстку (спасибо, скриншотеры!). Там же все помнят про пирамиду тестирования, и, скорее всего, у нас есть один или несколько наставников, готовых передать знания по инструментам и подходам.
Но самое главное: в идеальном мире мы уже умеем писать код к моменту, когда решили использовать автотесты в работе.
Как же все происходит в реальности? К сожалению, далеко не всегда обстоятельства складываются в нашу пользу, и к моменту, когда бизнес так или иначе требует внедрения в работу автоматизации проверок, мы можем столкнуться с теми или иными ограничениями:
- многие (или все) тестировщики в команде не умеют писать код, и в данный момент нет ни времени, ни «свободного» эксперта для их обучения;
- необходимо внедрять автоматизацию как можно скорее;
- неизвестно, будет ли необходимость поддерживать эти автотесты и, соответственно, имеет ли смысл инвестировать в их создание и настройку много времени и сил.
Привет, нам срочно нужны автотесты!
Я часто посещаю (а иногда и помогаю организовать) встречи, мероприятия и митапы, на которых мы говорим о насущных проблемах QA-инженеров. Увы, но опыт показывает, что ситуация и трудности, описанные выше, случаются чаще, чем того бы хотелось, а универсального решения, разумеется, нет. Значит, с каждой проблемой надо работать отдельно; но с какой стороны зайти?
Итак, к нам поступил запрос на внедрение автоматизации в проект. Один из хороших вариантов — начать с самого простого шага: задать необходимые вопросы.
- Цель:
- Зачем нам нужны автотесты? Для чего?
- Есть ли какая-то картина того, что ожидается?
- Текущие условия:
- Автоматизированных тестов бывает много: unit, API, GUI, e2e… Что уже есть у нас?
- Тестировщики совсем не понимают код, или какие-то базовые навыки есть?
- Какая вообще ситуация с автотестированием на проекте? В компании?
- Каковы сроки проекта?
- Каков размер команды (и QA, и разработчиков)?
- Насколько детальное требуется покрытие?
- Нужно ли добавлять тесты к процессам CI?
- Будет ли потом поддержка проекта? Тестов?
- Есть ли какой-то бюджет на инструменты для тестирования?
- Какие требования к окружению?
Получив вводные, можно двигаться дальше. Допустим, если времени много, команда большая, проект требует длительной поддержки, а автотесты нужны, чтобы обеспечить безукоризненную работу критически важных сценариев, то лучшим выбором будет обратиться к одному из существующих инструментов автоматизации, таким как 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 |
|
Katalon automation recorder |
|
Katalon Studio |
|
Testim |
|
Ranorex Studio |
|
Mabl |
|
TestProject |
|
Что же выбрать?
К сожалению или счастью, жизнь неоднозначна, поэтому выделить один лучший вариант невозможно: все решает ситуация на проекте, потребности заказчика и команды и прочие переменные, которые невозможно предугадать. Тем не менее, некоторые варианты могут использоваться в зависимости от того, насколько важен тот или иной параметр для итогового решения:
- Самый доступный: Selenium IDE
- Самый многофункциональный: Ranorex Studio / Katalon Studio / Testim
- Самый популярный: Selenium IDE
- Самый кастомизируемый: TestProject
- Самый подходящий для коротких проектов: TestProject
- Самый подходящий для долгих, больших проектов: Katalon Studio / Ranorex Studio / Testim
- Самый простой для «входа» в кодинг: Katalon Studio
Впрочем, вы и сами можете организовать сравнение и выбрать свой вариант. Для этого можно воспользоваться таким алгоритмом:
- Определяем критерии выбора:
- Задаем вопросы;
- Формулируем критерии (или берем готовые);
- Приоритезируем их, учитывая текущую ситуацию;
- Проводим сравнение:
- Учитываем критерии;
- Не забываем про здравый смысл;
- Согласуем с руководством и командой;
- Мотивация:
- Всегда помним, ЗАЧЕМ мы это делаем!
Подведем итоги
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
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: