Как стать автором
Обновить

Перспективы разработчика в автоматизации тестирования ПО

Время на прочтение 7 мин
Количество просмотров 5.2K
Всего голосов 14: ↑11 и ↓3 +8
Комментарии 17

Комментарии 17

Про вашу «заинтересованность» в кадрах легенды ходят)
Расскажите, пожалуйста, какие именно? Самим интересно.
1. Сотрудники и софт скиллы — просто откройте первую линку по запросу «Veeam отзывы сотрудников».
2. Шестиэтапное собеседование. И это не Amazon, который релоцирует в Новую Зеландию.
3. Обратная связь — слишком затянута по времени. Пока кандидат получит фидбек, он просто примет оффер от другой компании.
4. Одни и те же вакансии на hh висят по полгода, а это заставляет задуматься:
а). Либо компания лишь создает видимость найма кадров;
б). Либо внутренние процессы мешают найти сотрудника.

Комментарий написан, опираясь на личный опыт и опыт коллег.
1. Постоянно открываем, читаем, анализируем и делаем выводы. К сожалению, большая часть этих отзывов написана людьми не прошедшими собеседование и находящимися в состоянии мыши надутой на крупу. Что же до релевантной части отзывов, то можно сказать только одно — идеальных людей, которые нравятся всем на свете, не существует, так что мы тут не исключение.
2. А сколько этапов должно быть у собеседования, если мы, например, релоцируем в Прагу? Да и как-то не приходилось мне слышать про такие, хотя работаю в Veeam уже больше семи лет. Но даже если допустить, что действительно в какие-то отделы проводят шестиэтапные собесы (хотя ума не приложу, что они там делают) и продолжает эффективно выполнять свою работу, то, вероятно, они делают всё правильно и у них есть причины проводить столько этапов отбора.
3. Над обратной связью мы постоянно работаем и обязательно всегда её предоставляем. Но да, бывают определённые провалы и проводивший собеседование не всегда даёт моментальный фидбек. Так что вы снова нас подловили — мы не идеальны.
4. О, это мой самый любимый пункт. Я вам даже больше скажу: некоторые вакансии висят годами. Вот прямо действительно годами. И вы даже почти ловко раскрыли наш хитрый план по проведению собесов ради собесов и имитации бурной деятельности, но упустили один важный момент — компании уже почти 15 лет, и все 15 лет она растёт как не в себя. А для этого роста постоянно требуются люди. Так что да, много вакансий действительно висит и по полгода, и год, и даже больше. Но вы были очень близко к раскрытию нашего тайного плана по созданию видимости найма.

Спасибо вам за комментарий. Как видите, мы их действительно читаем, анализируем и делаем выводы.
Очень приятно, что общаетесь со своей аудиторией. Спасибо, что ответили на каждый из пунктов. Ни в коем случае не хотела принизить заслуги компании, и уж тем более задеть преданных сотрудников, которые посвятили ей не один год. Круто, что вы растете и развиваетесь. Собственно и комментарий был написан, поскольку я — ваш подписчик)
В любом случае желаю вам успехов и хороших коллег!
Расскажите, пожалуйста, какие именно? Самим интересно.
Легенд не знаю, но попасть в Veeam достаточно трудно. Хотя компания с мировым именем и для такого уровня, видимо, так и должно быть. Опишу свой опыт. Я сам проходил собес в Veeam. Решил тестовое, но лиды завалили на тех.интервью, сказав «Приходите через годик.» На тот момент не искал работу, поэтому не сильно расстроился. Но через время присмотрелся к компании, да и в новостях проскочили, и подумал «а почему бы и нет?!». Решил отправить отклик, но фидбека вообще не получил. Никакого. Ладно бы написали: «Не подходите» или «Вы — в черном списке с прошлого интервью», но просто молчание.
В целом интервью и сама компания в лице лидов и HR с прошлого собеса оставили положительное впечатление. Успехов вам!
Подтверждаю, во многие отделы у нас действительно весьма строгий отбор. То есть наша политика не заваливать проблемы людьми с рынка, а тщательно отбирать кандидатов, чтобы в итоге все были счастливы.

Если вы откликались в декабре и не получили ответа, это ненормальная ситуация и явно что-то сломалось. Киньте в личку на какую должность откликались и фио, будем разбираться и накажем виновных =)
В какой-то момент они осознают, что рутинные операции можно и нужно автоматизировать, либо просто желают попробовать себя в новом качестве.

Вообще-то, (1) сходу +$100 к зп, (2) уход от социального ярма "А чо, всю жизнь будешь тестером?!" и (3) ощущение постоянной движухи. На самом деле — ненужная суета, но поначалу это незаметно и воодушевляет.

Разработчик — это тот, кто пишет код. А что этот код делает — продукт для конечных потребителей или других разработчиков — это уже вторично.


На одну из озвученных проблем, кажется, вы так и не дали ответа — «Опасение потерять в карьерном росте и зарплате.». Сколько менеджерской работы нужно выполнять разработчику автотестов, чтобы приблизиться к зарплате разработчика веб приложений?


Ну и основная проблема, которую могут просто подразумевать, но не озвучивать. Разработка авто-тестов (чаще всего, веб приложения) — это узкая ниша. Точно такая же, как «Разработчик Shopify» или «Разработчик Wordpress». Большой ли спрос у компаний на разработчиков автотестов в сравнении с, например, Python/Javascript разработчиками?

Виктор, добрый день. Спасибо за комментарий.

Спрос на разработчиков автотестов достаточно большой. При этом не исключаю, что количество вакансий для продуктовых разработчиков на Python/Javascript может быть больше.

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

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

А что, если конкретнее? Возьмём условного middle+/senior- веб разработчика Javascript/Python/PHP/Ruby с ЗП $3000-$4000. Должен ли разработчик автотестов выполнять какие-то непрямые обязанности, чтобы получать такую же сумму (например, брать под свое крыло начинающих автоматизаторов, как указано в статье)? И сколько у вас в компании таких разработчиков?


Также, давайте представим ситуацию, что разработчик проработал у вас несколько лет в автоматизированном тестировании и решил поменять работу. Как по вашему, насколько дольше он будет искать работу в качестве разработчика автоматизированных тестов, чем разработчик JS/PHP/… ?


В целом, моя мысль в том, что разработчик автоматизированного тестирования — это просто очередная узкая ниша в разработке. И компания должна иметь это ввиду, ориентируясь в окладе. То есть, если предложение в этой нише невелико (например, потому что сложно и важно), то ЗП должна быть выше. А если предложение больше (как Wordpress например, с небольшим порогом входа) — то, конечно, уже другое дело.


Но говорить, что разработка автоматизированного тестирования — это та же самая разработка, — на мой взгляд, неправильно, потому что это довольно узкая, ответственная и объёмная по знаниям ниша.

Виктор,

Veeam — большая компания. Много проектов, много групп разработки. Задачи и обязанности можно обсуждать и находить компромисс. Если тому или иному специалисту ближе продуктовая разработка на Javascript/Python/PHP/Ruby, и он доволен своими задачами и бенефитами, то это его путь.

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

Выбор пути всегда подразумевает какие-то компромиссы. Трудно быть мастером на все руки. Если разработчик пишет код на C# (будь то сам продукт или автотесты для него), ему потребуются некоторые усилия, чтобы перейти на JS/PHP.

Безусловно, стезя разработки автотестов — важная, ответственная и объемная по знаниям. И потому ценная.
> поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп

Но, кстати, тоже скользкая дорожка. Ускорение очевидно, но приходится следить за структурой базы. Если между UI и базой есть какой-нибудь API, лучше им воспользоваться, а то изменение БД-записей напрямую всё же более опасная операция, чем использование API.
Luckman, да, совершенно верно.
А какая разница? Изменение структруы БД ведет за собой обновление контрактов API, если не автогенерируемый клиент, необходимо будет точно так же отслеживать изменения контрактов. А вообще в автотестах нужно и использование эмулятора(API) и SQL запросы -они не взаимозаменяемые, у каждого из них своя зона ответственности.
Один API-запрос может сразу в несколько таблиц залезать. Он может не измениться, даже если БД структура сильно изменится.
+ про API иногда бывает документируемым, и изменения в нём проще отслеживать, а про изменение структуры базы часто узнаёшь по факту красной регрессии.

В SQL лучше лезть только когда нет варианта с API, но да, это тоже бывает довольно часто.
Именно поэтому API и SQL не взаимозаменяемые, если есть логика приложения при формировании сущности — API, если ее нет, нужна операция клонирования с изменением нескольких полей, к примеру — SQL процедура.

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

Для разработки модуля, реализующего SQL шаги, можно применить Database-first подход. Таким образом будет отдельный шаг, который будет синкать entity, дальше можно заиспользовать верификацию контрактов(я делал через верификацию маперов в AutoMapper), и в случае, если верификация не пройдена, блокируется начало выполнения тестов.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий