Какой лучший старт для автоматизатора — Selenium WebDriver + Java (+ maven + junit) или WebDriver + C#?

Здравствуйте друзья!
Я немного программирую на C#/Java и думаю о карьере автоматизированиого тестировщика, но не знаю с какой технологией оставаться — .NET или Java?
Вроде и Java нравится, и проектов много, и перспективы с ней, вроде, лучше, но с другой стороны — очень много фреймворков/тулзов для тестирования, которые нужно много/долго настраивать, допиливать (только сегодня игрался с Webdriver+Java+maven+junit — в Eclipse тест с мавена не запускался, а когда переписал все тоже самое в Интелиджи Идее — все заработало! :) ).
В Visual studio, с другой стороны, все вроде намного легче да и курсов/книг побольше! Но это все только мое мнение, а как оно на самом деле?
Кстати, если уж такой разговор пошел, то ответьте пожалуйста, как у вас в фирмах идет процес тестирования с Selenium? Тесты пишуться в связке с junit+maven или без них и тесты запускаете прямо из Eclipse? И что было бы лучше для реалий, скажем так, Львова?
Спасибо!)

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сам как бы начинающий автоматизатор
Пользуюсь:
Selenium+Selenide+Junit / Java.
Почему такая сборка обьясню: Селенид для более простых решений, типа найти элемент, кликнуть, поиск массива элементов, проверка на наличии ссылки + эта божественная идея с таймаутом. Селениум же для более тяжелый решений типа драг енд дроп, клик енд холд и т.д.
Все остальное просто в процессе изучения освоилось, это я про JUnit.
Пишу все в Idea,что касается эклипса, то вначале им пользовался, но когда попробовал Идею, уже не мог остановиться.

UPD:
Хотелось бы узнать у тех, кто использует WebDriver — пользуетесь ли вы встроенной в Selenium IDE функцией конвертации/генерации записаного на IDE теста в C#/Java WebDriver тест?
Или все тесты пишете вручную?

IDE пишет простой и примитивный код. В реальной жизни не применим

Да, он генерит простой код, но как для какого то «каркаса» с дальнейшим допилом может подойти?

В рабочем проекте IDE не очень подходит, ибо серьёзные функции оно криво конвертит в код. Разве что использую IDE для очень банального и простого нагрузочного тестирования.

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

да no fucking difference at all

все что от вас требуется — это понимание того как это работает, не в последнюю очередь именно на опыте, и именно так и будут оценивать ваши умения при приеме на работу (если оценивающий в адеквате — но с неадекватными работать себе дороже)

а не по количеству зазубренных абзацев из мануала конкретного инструмента

в общем — хватит флудить, чертовы джуниоры, марш руками работать!
и головой

У нас на проекте используется связка TestNG(для автоматизации получше будет чем JUnit)+Ant+ Silk4J+Eclipse. Проект десктопный.
На предыдущем моем проекте: C#+Telerik+MSpec, проект был вебовый.
Думаю, зная Java/C# на достаточном уровне у вас проблем с поиском работы быть не должно.
Фреймворки вещь вторичная, на каждом проекте свои. Можете ради интереса и строчки в резюме потыкать все популярные, но это не критично.

Начинать надо с того что тебе проще дается. Если интересней С#, то начинай на нем, если Java, то копай ее. Если знаешь ООП, то в принципе, тесты сможешь писать на любом языке, зная отличия технологий.
Ну на крайняк начинай с тех технологий, по которым больше вакансий в ближайшей к тебе конторе

Если знаешь ООП, то в принципе, тесты сможешь писать на любом языке

Фраза, достойная занесения в палату мер и весов.

Кстати, если кому пригодится — отличный бесплатный курс.
www.udemy.com/...iver-with-java

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

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

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

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

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

плюс возможность быстрого фикса(в случае «категорически необходимой» смены идентификаторов контролов, например) — тоже хороший аргумент.
P.S. уточню. если автотестер делает ревью изменений — это может быть реальным преимуществом команды: кроссфункциональность и всё такое; риски минимизированы

В целом, иногда так действительно удобнее, но никак не "

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

А для вас работа девелопера заключается в гененировании кода? То что вы описываете, ну максимум, можно отнести к кодеру. А разработчик должен все-таки думать и отвечать за качество своего кода. Понятно, что некоторые вещи могут пропадать из его внимания, потому как он сконцентрирован на технической реализации, но если он оставляет явные косяки или не проверяет свой функционал перед тем как отдать в тестирование, то цкнность такого разработчика крайне низкая. А подхватывать чужую работу это как бы одна из составных частей современных методологий разработки.

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

А подхватывать чужую работу это как бы одна из составных частей современных методологий разработки.
Ничего подобного, программист не должен подхватывать работу художника, художник не должен подхватывать работу менеджера и т.д.
Сотрудник отдела может заменить другого сотрудника этой же специальности\отдела\направленности, но совсем не должен делать чужую работу.
Если QA по какой то причине не успевают, то нет ничего страшного в том, чтоб им помочь.
А вы доверите программисту принимать решения, к примеру, о состоянии билда, если QA не успеют этого сделать?
но если он оставляет явные косяки или не проверяет свой функционал перед тем как отдать в тестирование,
при чем тут это вообще?) речь шла о ситуации, когда по какой-то причине девелопер должен подменять тестировшика...я и задал вопрос, как вообще может возникнуть такая ситуация\необходимость, если процесс нормально налажен?
В идеале автоматизация должна быть написана на тех же технологиях что и проект
Почему девелопер должен заменять автоматизатора а не другой автоматизатор?
А затем, что в один прекрасный день фирму могут, как раковая опухоль, заполонить реалити хакеры, считающие, что «QA не нужны» ©.

Ну если вы рассматриваете только большие проекты (от 15 человек) , то таких ситуаций дествительно не так уж много. Ну у нас к примеру на прошлом проекте девелоперы привлекались чтобы порефакторить тестовый фреймворк. Но вы не учитываете огромный процент проектов, где 1-2 QA и если один уходит в отпуск, особенно если он единственный, помощь девелоперов просто необходима.
А по поводу совмещения и чужой работы, то чужой работы не существует. Есть проект и скоуп который надо сделать и зачастую, если объемы не стабильные, то будет нужна именно такая команда, в которую вы видимо не попадете en.wikipedia.org/...functional_team

Но вы не учитываете огромный процент проектов, где 1-2 QA и если один уходит в отпуск, особенно если он единственный, помощь девелоперов просто необходима.
объясните, а кто девелоперу даст право «помогать» куа? а если он «помог», сказал что «вооружение в бою работает» а окажется что он не знал, что когда-то тут был баг, при котором после второй перезарядки оно перестает работать и этот баг опять вылез и его пропустили на продакшен? У 20% пользователей блокер, они не могут полноценно играть...нужно вливать какой-то «быстрый фикс»...а всё потому, что кто-то послал девелопер решил «помочь».... Как быть вот в такой ситуации? Может быть лучше поднять вопрос о нехватке людей, если отдел не справляется, а не делегировать задачи соседям?
А по поводу совмещения и чужой работы, то чужой работы не существует. Есть проект и скоуп который надо сделать и зачастую, если объемы не стабильные, то будет нужна именно такая команда, в которую вы видимо не попадете
Т.е. вы считаете, что в функциональной команде каждый должен иметь возможность помочь другому? Куа должен помогать художнику дорисовать дерево(если он не успевает) а художник должен помочь программисту дописать рендеринг 3д объектов? Да, в такую команду я не попадаю и не понимаю, зачем попадать...

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

Если нужно помочь притащить стол или оборудование, то не будет ничего страшного, если вы, программист, это сделаете (а не будете рассказывать про найм грузчиков)

Если QA по какой то причине не успевают, то нет ничего страшного в том, чтоб им помочь.

Да, представте себе, если вы разольете чай, то ...
Если нужно помочь притащить стол или оборудование, то...
О, да, отличный пример, это ж действия, которые предполагают специализацию!
А еще программист запросто ремонтирует сплит-систему кондиционирования, настраивает роуты на произвольных компьютерах, заправляет принтеры, а при соответствующем настроении — ставит «металло-пластиковые» окна :)

Я вас умоляю, специализация. И сколькож вам изучить придётся, чтоб начать писать автотесты? (учитывая, что мы говорим о кодировании тестов, а не составлении тест-плана)

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

Мы ведь сейчас говорим о «быть на подхвате», т.е. прийти в готовый фремйворк и написать пару тестов по примеру.

А делать с нуля — да, надо набраться опыта (по сути — поработать в уже организованных проектах)

и написать пару тестов по примеру
ну, это уже как бы не совсем
Если QA по какой то причине не успевают, то нет ничего страшного в том, чтоб им помочь

А что ж это? Немного не успевают, с моей точки зрения, это когда есть тест-кейсы, но не все выполнены к моменту реализации фичи.

А когда фреймворк не написан — эт знаете уже залёт...

Ну вы вот сразу выдаете отсутствие опыта по старту проекта с нуля или развитию прототипа. К тому же фреймворк еще и развивать надо с развитием проекта...

Хех Константин, просветите меня глупого, с каких пор «спецы немного не успевают», означает что у них ещё конь не валялся.

абы-какие автотесты уже писал.

учитывая, что мы говорим о кодировании тестов, а не составлении тест-плана
правильно ли я понимаю, что «кодирование теста» — наиболее времязатратная операция в процессе? если да — то, может, нормальные pageObject’ы писать(не знаю, как это в случае не-web приложений называется) и повышать абстракцию?
а если нет — какой смысл в экономии на спичках ценой времени разработки?
а если нет — какой смысл в экономии на спичках ценой времени разработки?
Вы вообще понимаете смысл слова «помочь»?

Это когда кьюэй не успевает дописать 5 автотестов из 50 сегодня до вечера, и «мего_ПМ» решает поручить программисту помочь написать эти 5 тестов... а потом оказывается что он не учел особенности проверки фичи и три из этих автотестов выдали пасс вместо фейла.
В этом и есть смысл ситуации, когда людям поручают делать чужую работу)

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

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

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

я ежедневно смотрю в код, с которым некогда «помогли».
и потихоньку это рефакторим.
скажите, а потом, когда «программисты немного не успевают», им помогают QA, я правильно понял идею?

я ежедневно смотрю в код, с которым некогда «помогли».
и потихоньку это рефакторим.
1. Ревью у вас нет?
2. Лучше было бы без помощи зафейлится?

1. ревью есть. а на момент написания кода, возможно, с ревью тоже «помогали».
2. то есть, как — пускать пыль в глаза("все выполнено, проблем нет") — это success, а перенести сроки по части функционала — это fail?
P.S. солью-ка я, пожалуй, этот спор. а то вообще печально(

1. ревью есть. а на момент написания кода, возможно, с ревью тоже «помогали».
Это бугагашеньки. Вобщем сами проморгали, сами и исправляем. Всё ок.
то есть, как — пускать пыль в глаза("все выполнено, проблем нет") — это success, а перенести сроки по части функционала — это fail?
Знаете, код никому сам по себе не нужен. И даже фичи никому просто так, как исскуство, не нужны. Все должно выполнять свою задачу. Если очень важно успеть в срок (простой пример — успеть попасть магазином в период новогодних продаж), то на мелкие огрехи вполне можно закрыть глаза — и это правильно.

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

ох, про ревью аж дважды написано! однако, я там даже и не спорю.
а давайте, побеседуем про «важно успеть в срок» и «на мелкие огрехи закрыть глаза».
если важно успеть в срок, то зачем программисты «помогают QA», вместо того, чтоб таки успевать, закрывая глаза «на мелкие огрехи»?
сначала — категоричность, а потом — «бизнес важнее программерского перфекционизма».

«бизнес важнее программерского перфекционизма».
Верно. Покрытие приёмочными тестами — это бизнес. Идеальный код в приёмочных тестах — это программерская эстетика. Теперь понимаете?

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

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

Спасибо за ответ. А как, вообще, Selenium тесты пишите — с junit, или чисто как Java app? Дело то в том, что код одного и того же теста будет отличаться (в junit он труднее, как мне кажеться :)

а с чего вы взяли что я пишу селениум тесты или вообще занимаюсь автоматизацией?)

тесты запускаете прямо из Eclipse?
разве что на этапе разработки и отладки....
Вот потому и предположил что у вас на фирме/на проекте есть дело с Силиниумом

А почему рассматриваете автоматизацию только под веб и только «штамповку» тестов, где ничего интересного нету(через пару месяцев уже начнется лишь рутина) и особо никаких знаний не нужно(кроме IT базы)?
По теме:
для ваших целей(для селениума и ему подобных) знания любого языка получаются максимум за месяц и абсолютно не важно, будет это C#, java, python или похапэ... нету смысла привязываться к какому-то определенному....
но для старта я бы советовал начать с того, что больше требуется\где проще найти первую работу в вашем городе, или заточить знания и резюме под определенную компанию ...

Да, понимаю, язык — это не проблема, но мне больше всего не нравиться (что в принципе являеться плюсом стека, но моим минусом) то, что для запуска тестов, сейчас я говорю только о Selenium, нужно еще знать/пользоваться кучей дополнительных тулзов — это в Java, а с C#, такого нет, не нужно скрещивать junit с webdriver, а потом собирать и запускать тест мавеном. Хотя, знаю что можно обойтись и без мавена, а запускать тест как Джава аппликацию, но как я понял если Java, то значит и эта братия (maven, junit).

По барабану. А вообще опытные автоматизаторы знают несколько языков, почти всегда это и Java и C#, часто Ruby, все на хреновастеньком уровне правда, но все же.

Если я доросту до опытного автоматизатора, то тоже буду эту кипу языков знать — тогда это не будет проблемой :) Другое дело сейчас как поступить?

Большинство моих знакомых автомейшон-куа начинали c#

все на хреновастеньком уровне
«автоматизаторы» для веба- да, тут не поспоришь...

Сам точно не знаю но :
Selenium WebDriver + Java (+ maven + junit)
Явно перспективней чем:
WebDriver + C#
Это сто пудов !!!

Лол. Просто лол.
Это потому что слов больше?

Подписаться на комментарии