Добрый день, господа.
Недавно у меня возник небольшой спор по теме того что лучше codeless тулы (типа Katalon Studio и т.п.) либо писать автотесты самому(в моем случае webDriver + Python).
Я уверен что написанные вручную тесты будут лучшим решением, чем накликать их мануально с помощью какой-то тулы.
Ведь не зря же есть куча вакансий автоматизаторов где требуются знания языков программирования, знания webDriver, знания фреймворков для автоматизации?
Я имею небольшой опыт в автоматизации и не совсем вижу целосность всей картины, так сказать…
Вот некоторые преимущества, которые ощутил лично:
Ты четко понимаешь что за чем идет в тесте
У webDriver есть возможность запускать паралельно несколько окон браузера в одном тесте
Очень хочу услышать мнения более опытных специалистов в автоматизации.
Все эти рекордеры работают только тогда, когда нет серьезной конфигурации и разных зависимостей от данных и условий.
Если меняется логика в одном месте, скорее всего придется перезаписывать все затронутые тесты, в то время как через код вы поменяете только там, где нужно и пофиксите все тесты сразу.
Вы все контролируете когда пишите тесты и локаторы сами, чем сложнее система тем больше шансов упереться в баги, глюки и низкую производительность. Я это почувствовал когда работал с CodedUi
Рекордеры - это автоматизация на уровне “2+2=4”. Не вижу никакого преимущества в использовании рекордеров для любого человека, способного сделать рефакторинг, добавить дата провайдер, разобраться, какие dependencies надо добавить и для чего, провести сложную проверку полученного результата. Если такого человека нет, вообще не вижу смысла в такой автоматизации. Реально она ничего не проверяет.
ну вы очень уж грубо отзываетесь о подобных инструментах, заостряясь на необходимости что-либо проверять.
но не следует забывать, что рекордеры - это не инструмент автоматизации тестирования, это инструмент автоматизации как таковой.
а вот что именно вы будете пытаться автоматизировать - это ваше дело
если вы хотите автоматизировать тестирование веб или мобилки, тем более в условиях agile разработки, то легче поддерживать код
а если вы окажетесь в условиях, когда кроме абстрактных sikulix использовать ничего нельзя? сидишь себе накликиваешь какие-то действия, из консольки запускаешь, красота да и только
так что я был бы осторожен в оценках, потому что надо исходить из задач, требований и ограничений
У меня есть очень простой пример.
Как-то меня попросили написать тест, который сохраняет его результат (passed/failed) и время в базе данных.
Попробуйте это сделать с помощью codeless tools
Если по-простому, то дает все возможности языка программирования, на котором идет сама автоматизация. Если больше сказать, то легче управлять, поддерживать проект.
Автоматизация с кодом дает вам возможность контролировать все самому, codeLess решения вас в этом ограничивают.
Вообще с кодом или без это зависит от того что вам нужно, какие перед вами стоят задачи и насколько codeLess инструмента хватает чтобы их покрыть.
Самое сложное не написать тесты, а поддерживать / изменять / адаптировать / и понимать, почему они сломались.
В случае с решениями без кода менять тесты почти что невозможно.
Также очень большой минус, когда вы работаете командой. Вас 2 и более человек, у вас есть процесс ревью, вы должны работать вместе над одними участками кода. В решениях без кода вес репозитория очень часто значительно больше + там много дополнительных файлов/настроек/конфигурации, которые надо изменять вручную или класть в репозитории, что приводит к дополнитьльному гемору.
Также интеграция с CI/CD (gitlab, jenkins,. teamcity, bamboo) не такая гибкая, часто очень глючная, работающая на половину.
Другая проблема - коммьюнити очень часто очень слабое, исходный код не посмотреть, самому напилиником продукт не допилить, в итоге только страдать.
И напоследок, переход и миграция на что-то новое/другое часто невозможно, приходится просто все с нуля писать.
А мне кажется всё гораздо проще
Если человек знает хотя бы на джун уровне какой-либо ЯП, то естественно нужно писать тесты используя ЯП, без всяких рекордеров.
А если человек новичок, то для вхождения в АТ можно начать конечно же со всяких рекордеров.
Но засиживаться на них не стоит.
Здесь частенько мелькают истории о том, что например приложение нельзя никак автоматизировать, только через Sikuli или подобные программы.
Лично я считаю, что если приложение можно автоматизировать только через скриншоты - то такая автоматизация не нужна вовсе. Если там конечно не 5 тестов будет.
Сидеть и тратить 90% времени на правку тестов - такая себе автоматизация.
тут надо делать уточнение, что недолго - это ну максимум месяц. И потом уже переписывать все на ЯП.
И сразу команде и начальству своей в открытую все говорить реальное положение дел.
А то вот я видела проект, который 4 года писали на аналоге Sikuli, 2000 тестов без IDE (в стремной IDE, а-ля notepad++)
Именно.
Большинство людей (из тех что я знаю, и это не только автоматизаторы, но и разработчики и аналитики) при постановке задачи от начальства молча говорит “Ок, сделаю”, хотя прекрасно понимают, что поставленная задача либо должна делаться в другом месте и с использованием других технологий, либо же вообще не должна выполняться в том виде, в котором она поставлена
Но как говорится - собака лает, караван идет, большинству пофиг, нет идеи/общей цели, деньги платят и хорошо )
Да всё просто. Когда ты пишешь сам тесты, ты понимаешь +/-, что и как работает. Когда ты нащелкиваешь, для тебя это чёрный ящик. Что там заложил разработчик и как оно работает, тёмный лес. Плюс некоторые готовые решения стоят денег, как например TestComplete.
Также практически все автоматы без открытого исходного кода, что добавляет проблем, если что-то не работает или работает не так.
Codeless инструменты не дадут тебе той гибкости, свободы и контроля, которую тебе дает полноценная автоматизация тестирования с помощью кода. Тот же Каталон имел множество проблем и недостатков в тот момент, когда мы изучали инструменты для внедрения на проект.
Кодлесс не равно рекордер. Посмотрите на fitness это нормальный подход, когда человек владеющий ЯП пишет обвязку автотестов (посути АПИ), а мануал тестировщики, бизнес аналитики, пм и клиент заполняют тестовые случаи. Такой подход работает и приносит много пользы.
Cucubmber / Fitness / Specflow - я бы все же не назвала это Codeless решением, так как это подразумевает наличиет на полноценном фуллтайме нормального автоматизатора / проограммиста чтобы писать новые обвязки / чинить их и тд
Вы не забывайте, что тулзы - это прежде всего тулзы с помощью которых вы сможете быстро накидать тесты и т.п. без необходимости знать ЯП.
Я, например, часто пользуюсь этим, чтобы не поддерживать то, чем я в скором времени не буду пользоваться. Например, действия в стороннем ЛК при интеграции и т.п. + тулзы позволяют использовать свой собственный браузер (уже настроенный с нужными расширениями)
Удивляюсь, почему так много людей радикально против. В Каталоне полная экосистема для автотестирования. Каждое действие настраивается, можно делать кастомные степы через код на груви. По сути это эволюция: IDE чисто для тестов.