Почему автоматизация с кодом лучше codeless инструментов?

Добрый день, господа.
Недавно у меня возник небольшой спор по теме того что лучше codeless тулы (типа Katalon Studio и т.п.) либо писать автотесты самому(в моем случае webDriver + Python).
Я уверен что написанные вручную тесты будут лучшим решением, чем накликать их мануально с помощью какой-то тулы.
Ведь не зря же есть куча вакансий автоматизаторов где требуются знания языков программирования, знания webDriver, знания фреймворков для автоматизации?

Я имею небольшой опыт в автоматизации и не совсем вижу целосность всей картины, так сказать…
Вот некоторые преимущества, которые ощутил лично:

  1. Ты четко понимаешь что за чем идет в тесте
  2. У webDriver есть возможность запускать паралельно несколько окон браузера в одном тесте

Очень хочу услышать мнения более опытных специалистов в автоматизации.

2 лайка

Как по мне:

  1. Все эти рекордеры работают только тогда, когда нет серьезной конфигурации и разных зависимостей от данных и условий.
  2. Если меняется логика в одном месте, скорее всего придется перезаписывать все затронутые тесты, в то время как через код вы поменяете только там, где нужно и пофиксите все тесты сразу.
  3. Вы все контролируете когда пишите тесты и локаторы сами, чем сложнее система тем больше шансов упереться в баги, глюки и низкую производительность. Я это почувствовал когда работал с CodedUi
4 лайка

Рекордеры - это автоматизация на уровне “2+2=4”. Не вижу никакого преимущества в использовании рекордеров для любого человека, способного сделать рефакторинг, добавить дата провайдер, разобраться, какие dependencies надо добавить и для чего, провести сложную проверку полученного результата. Если такого человека нет, вообще не вижу смысла в такой автоматизации. Реально она ничего не проверяет.

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

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

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

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

2 лайка

У меня есть очень простой пример.
Как-то меня попросили написать тест, который сохраняет его результат (passed/failed) и время в базе данных.
Попробуйте это сделать с помощью codeless tools

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

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

Самое сложное не написать тесты, а поддерживать / изменять / адаптировать / и понимать, почему они сломались.

В случае с решениями без кода менять тесты почти что невозможно.

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

Также интеграция с CI/CD (gitlab, jenkins,. teamcity, bamboo) не такая гибкая, часто очень глючная, работающая на половину.

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

И напоследок, переход и миграция на что-то новое/другое часто невозможно, приходится просто все с нуля писать.

8 лайков

А мне кажется всё гораздо проще :slight_smile:
Если человек знает хотя бы на джун уровне какой-либо ЯП, то естественно нужно писать тесты используя ЯП, без всяких рекордеров.

А если человек новичок, то для вхождения в АТ можно начать конечно же со всяких рекордеров.
Но засиживаться на них не стоит.

Здесь частенько мелькают истории о том, что например приложение нельзя никак автоматизировать, только через Sikuli или подобные программы.

Лично я считаю, что если приложение можно автоматизировать только через скриншоты - то такая автоматизация не нужна вовсе. Если там конечно не 5 тестов будет.
Сидеть и тратить 90% времени на правку тестов - такая себе автоматизация.

1 лайк

тут надо делать уточнение, что недолго - это ну максимум месяц. И потом уже переписывать все на ЯП.

И сразу команде и начальству своей в открытую все говорить реальное положение дел.
А то вот я видела проект, который 4 года писали на аналоге Sikuli, 2000 тестов без IDE (в стремной IDE, а-ля notepad++)

1 лайк

Именно.
Большинство людей (из тех что я знаю, и это не только автоматизаторы, но и разработчики и аналитики) при постановке задачи от начальства молча говорит “Ок, сделаю”, хотя прекрасно понимают, что поставленная задача либо должна делаться в другом месте и с использованием других технологий, либо же вообще не должна выполняться в том виде, в котором она поставлена :slight_smile:
Но как говорится - собака лает, караван идет, большинству пофиг, нет идеи/общей цели, деньги платят и хорошо )

6 лайков

Да всё просто. Когда ты пишешь сам тесты, ты понимаешь +/-, что и как работает. Когда ты нащелкиваешь, для тебя это чёрный ящик. Что там заложил разработчик и как оно работает, тёмный лес. Плюс некоторые готовые решения стоят денег, как например TestComplete.

Также практически все автоматы без открытого исходного кода, что добавляет проблем, если что-то не работает или работает не так.

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

И Selenium IDE имеет множество проблем и ограничений. И практически все автоинструменты грешат этим

1 лайк

Кодлесс не равно рекордер. Посмотрите на fitness это нормальный подход, когда человек владеющий ЯП пишет обвязку автотестов (посути АПИ), а мануал тестировщики, бизнес аналитики, пм и клиент заполняют тестовые случаи. Такой подход работает и приносит много пользы.

5 лайков

Cucubmber / Fitness / Specflow - я бы все же не назвала это Codeless решением, так как это подразумевает наличиет на полноценном фуллтайме нормального автоматизатора / проограммиста чтобы писать новые обвязки / чинить их и тд

1 лайк

@Dmitrij_Belotserkovskiy с какой целью был задан вопрос изначально? Хотелось бы больше контекста и описание вашей проблемы.

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

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

1 лайк

Все просто - гибкость. По сути чем больше гибкость, тем больше наворотов и сложность самого инструмента, но не всегда.