Карьера: в автотестеры или в разработчики?

Всем привет! Работаю мануальщиком, потому что в недалёком прошлом не получилось устроиться разработчиком, а в qa попал на бОльшие деньги, чем ожидал даже от разработки. Но надо куда-то двигаться , и в текущей конторе, после того, как закончится проект, я буду переходить либо в автотестеры, либо в разработчики, языки за время работы сильно подтянул(Java, второй C#), в принципе выполняю любые типовые джуниорские задачи, работа с базами, сервера, и так далее.

Сертификаты имеются и ISTQB и по джаве и по c#(да-да они никому не нужны, но они тем не менее есть), в общем гребу примерно на одном уровне обоими видами гребли. И поэтому хочу спросить у вас, дорогие автотестеры, насколько это направление востребовано и оплачиваемо. Насколько карьера автотестера развивается быстрее, чем карьера разраба , какие плюшки я от этого получу, и где таки меньше головняка.

В selenium/appium тоже умею и мне это даже очень нравится.
Hh ситуацию не проясняет , потому что вакансий немного и зарплатные вилки не обозначены.
Заранее спасибо за ответы!

Автотестеры скоро вымрут. Как правило это такие недопрограммисты. Пока есть выбор - вали в девы

1 лайк

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

9 лайков

И как зарплаты и перспективы автотестера?

Джун мидл до $1,5k, синьор до $3k, техлид в тестировании от $3k и выше, тут уже зависит от компании, проекта, заказчика и т.д. Данные очень примерные, само собой. Разрыв по зарплатам между разработчиком и тестировщиком тем выше, чем выше сопоставляемые ранги. У разработчика соответственно зп в среднем выше. Минимальный порог знаний в языках для эффективной работы у автоматизатора ниже чем у разработчика. В случае с разработчиком мотивация совершенствоваться будет естественной, потому как тут зависимость прямая - больше знаешь/умеешь - больше востребован. В автоматизации достигнув определенного уровня только самолично подгоняя себя можно продолжить развиваться в техническом плане, искать новые челенджи, новые проекты. Потому как вундеркинды автоматизаторы не так уж много где нужны. Вакансий такого типа единицы. В подавляющем большинстве случаев автоматизаторы нужны как крепкие рабочие лошадки, которые придут и разгребут эту кучу того что там бесконтрольно копилось с момента старта проекта и будут следить чтобы впредь подобного не происходило.

4 лайка

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

1 лайк

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

1 лайк

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

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

1 лайк

Ну тут даже мне с моим скромным опытом сложно с вами согласиться. Зеленые юниты и интеграционка вообще никак не говорят о том, что все работает правильно. Просто если их не писать, то это значит, что на тест попадет заведомо нерабочий билд. На нашем проекте сейчас нет проблем с дедлайнами, очень прошаренный тимлид , и изменения в проект не вносятся без основательного ресерча, как эти изменения лучше сделать, и качеству кода уделяется особое внимание, вплоть до мелочей. Это уменьшает количество найденных мной багов на регрессе, но баги все равно есть, их не мало, и многие из них критичные.
UPD: То что, что-то работает на локальном окружении у разработчика, это вообще никак не говорит о том, что это будет работать в реальных условиях. Окружение разработчика это этакий сферический конь в вакууме. Множество раз вылезали баги, связанные, например с форматом времени или региональными настройками aka культурой.
UPD2: Да и вы уж меня извините, но как вы представляете себе хоть сколько-нибудь сложную систему, возьмем хотя бы сервис по продаже авиабилетов или чего-нибудь типа этого, без регрессии, ручной или автоматизированной - не суть важно. Чем сложнее система тем выше вероятность багов, которые могут парализовать бизнес, пусть хоть там разработчик юнитами обтестируется. В принципе, я могу понять ваше отношение к тестированию, потому что во многих стартапах и на мелких проектах тестировщики отсутствуют в принципе - они там и не особо нужны, лишь дополнительная финансовая нагрузка. Никто не говорил, что наша профессия везде нужна и применима.

3 лайка

Если эта фраза сказана не в контексте “не надо сюда соваться, нам и без вас хорошо”, то вы очень и очень неправы. Сейчас стоимость содержания одного автотестера обходится компании намного дешевле, чем содержание нескольких мэнуал-qa. Плюс менеджеры хотят автоматизацию, они даже иногда не понимают до конца все аспекты, но хотят.
Недопрограммисты - это вообще меня убило) Поверьте, автоматизатор имеет гораздо более широкие задачи на своем языке при работе с тестами, чем средний дев. Ибо дев как правило варится в своем котле, а у автотестера задачи: оберни отдельный qa хост в ssh методы, работай с базой перед тестами, если не напрямую, то работай через API, затем возьми селениум, придумай подходящий паттерн, ибо PageObject в чистом виде сегодня уже применить нельзя. Далее подними мок на экстернал API чтобы тесты не зависели от внешних вызовов. А что там в самих тестах приходится применять - одному xpath’у известно. Где не хватает методов селениума или они не стабильно работают - пиши джаваскриптовые костыли. И с утра тесты должны быть зеленые.
Так что о каких недопрограммистах идет речь - не понимаю. И да, попробуйте не найти документацию на тесты и докстринги на методы. А у вас там что? Все методы юниттестами покрыты?

7 лайков
  • Если вопрос исключительно о деньгах - то хороший автотестер легко может получать зарплату под 4к$. Плюс, легко можно при надобности взять заказ (порядка 10-20 долларов в час, или больше). Впринципе в том же Киеве уже легко можно шиковать и ни в чем себе не отказывать. Ну а убедить бизнес что вам нужно платить архитекторскую зарплату - это уже ваша дальнейшая после лычки лида задача.
    (Статистика зарплат програмістів, тестувальників і PM в Україні | DOU)

  • Сертификаты не страшно, помогают иногда и автомейшену и деву.

  • Направление сейчас в целом ощущаю все больше и больше нужно. Думаю очень хорошо можно вырасти если знаешь штуки типа NodeJS, Python именно в контексте тестирования. Так же никто особо не умеет строить инфраструктуру тестовых ферм, настраивать всякие контейнеры в тестах и тестить сами контейнеры. Ну и я вижу очень много потенциала уходить на уровни ниже - API, всякие контракты, Client Side Performance, интеграции, и дальше оценивать тестируемость кода, ревьювить юнитесты и заниматься их конфигурированием. Знаешь эдакий трушный Software Developer in Test.

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

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

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

14 лайков

Почитай про SDET. На Джинне конторы из ТОП3 отрывают таких с руками.

1 лайк

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

P.S. Но свою работу люблю не за з.п. :slight_smile:

Если брать по деньгам, то ЗП разраба хоть ненамного, но всё-таки выше, чем ЗП автотестера такой же квалификации. Тут скорее вопрос, что больше нравится: писать формочки и кнопочки или писать то, что тестирует формочки и кнопочки.
Ещё ньюанс: фреймворки и языки в разработке сменяются достаточно быстро и то, чем ты гребёшь сегодня, может быть вполне бесполезно завтра, особенно если рассматривать длительную карьеру (5+ лет) на одном проекте. По её завершению вполне может оказаться, что Ваши практические знания устарели и надо доучить 1, а лучше 2 или 3 новых фреймворка, чтобы быть конкурентноспособным. Фреймворки для автотестирования устаревают не столь быстро. Могут появиться новые версии, но, зная старую, перейти на новую проблемы не будет. Описанный выше ньюанс может получиться, если на проекте используется самописный фреймворк.
Насчёт карьеры, как вариант, можно рассмотреть карьеру: автотестер - лид автотестеров - QA Manager. Или автотестер - лид автотестеров - Test Architect.
В целом, карьера тестировщика более быстрая, чем разработчика.

2 лайка

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

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

2 Эффективность вашей работы зависит от эффективности автоматизации в целом на проекте. А эффективность автоматизации зависит от множества факторов. Одним из них является вовлеченность разработчиков. Таким образом, если вам попалась команда из разрабов, которые не очень вовлечены в тестирование, не делают специально для вас API, mock`и и т.д. То ваша автоматизация как правило не эффективна. Соответственно и ваша работа. Т.е вы в заложниках и поменять ситуацию рядовому автоматизатору не легко.

3 Низкий уровень осведомленности по автоматизации в странах СНГ. Здесь я имею в виду практики, инструменты и т.д. Если вы посмотрите на вакансии автоматизатора, там зачастую можете видеть Cucumber JVM, но если посмотрите на проект, то никакого BDD там как правило нету. Сюда же можно добавить непонимание бенефитов автоматизации, как правило менеджеры хотят видеть только красивые отчёты.

4 Фреймворк автоматизации - это до сих пор бич множества проектов. Люди которые никогда не программировали, не тратили своё личное время на разработку своих pet проектов или контрибьюта в Open-source хотят проявить себя в разработке своего фреймворка. Это понятно, однако грустно.

4 лайка

Ни в ВК и в ФБ нет выделенных тестировщиков. В майкрософт были тысячи тестировщиков, что никак не влияло на качество первых версий. Реальное тестирование все равно проходило в проде по факту. Ну это только известные факты. Работа в аутсорсе не дает реальной картины IT-мира. В реальном мире люди покупают продукты не потому что они надежные и красивые, а потому что они им нужны и у них есть договоренности которые они обязаны соблюдать. Поэтому скорость выкатки фич гораздо важнее чем “надежность”. Девиз фейсбука “Fail fast”.

Де факто приемочным тестированием фич все равно занимаются менеджеры. И не важно какую орду тестировщиков вы посадите туда - баги все равно будут.

Про окружения - ну вы и на тестовом окружении никогда не воспроизведете продовскую нагрузку.

Поэтому следующим уровнем после тестирования в “деве” является мониторинг, который позволяет быстро выявить все ошибки в реальных условиях, которые ни вы ни коллеги разработчики выявить бы не смогли никогда. Ну может через полгода кодфриза и непрерывных экспериментов.

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

1 лайк

в вк нет тестировщиков?) серьёзно?)

Думаю, рассуждения на тему “какая профессия изживёт себя первой” не лучший критерий, т.к. оба направления будут востребованы до тех пор, пока их не заменит крутой AI. А так как такого не случится в обозримом будущем, то не стоит зацикливаться на этом.
Что касается критерия ЗП, то хороший специалист всегда будет востребован и хорошо оплачиваем.
Я бы сказал, что на первое место в вашем решении должны выходить критерии ваших желаний и целей в жизни в целом (скажем, Кем и Где вы видите себя через 5-10 лет: например, вы пожелаете работать в гугле в Силиконовой долине или вы хотите быть крутым архитектором в своей стране и любое др.), а также предпочтений и внутренних ощущений (вы больше программист или тестировщик). И, естественно, в таких делах не без удачи :slight_smile:

2 лайка

Не нашел пруфов, что в ВК и facebook нет выделенных тестировщиков. ВК:VK.com | VK в группе есть заметки об отделе тестирования. Так же при гуглении как тестирует facebook, всплывают различные заметки. Единственная разница в том, что в facebook работают инженеры, которые занимаются более сложными вещами, чем подавляющее большинство: типа настройки ферм с сотнями моделей разных смартфонов. Опять таки , то , что такие продукты Майкрософта, как например Sharepoint вообще доходят до релиза и их кому-то даже продают, тут безусловный эффорт отдела тестирования.
Но я не спорю с вами, на самом деле просто я не смотрю с точки зрения принесения какой-то эфемерной пользы продукту и не идеализирую, как многие, работу разработчика. Если рассуждать в таком ключе, то наибольшую пользу приносят продажники, а не it специалисты.
Разработка-это создание формочек и перегон данных туда-сюда. Тестировщик, автотестер, могут приносить пользу, но это задача менеджера и процессов. Мы можем попробовать что-то изменить, но это не всегда целесообразно.
Хрен его знает, после всех высказанных мнений, я народ ещё на тостере спрашивал, как раз по тем критериям по которым я выбираю(конкуренция, трудоемкость, скорость карьерного роста, мобильность в профессии), в принципе мне это подходит.

3 лайка

Пункты 2 и 3 – рабочие моменты, с которыми можно бороться. Что касается 1 и 4, то это действительно удручает. Очень мало людей понимают, что нужно учиться. Никаких книг, блогов или онлайн курсов. Много людей приходят на проект, разбираются с фреймворком-монстром и тем и живут. Ну может быть еще купят пару курсов на udemy, но за год так и не посмотрят ни одного. И это сильно удручает, отсюда и такое отношение к профессии : “а зачем они нужны, они же недопрограммисты” :slight_smile: Конечно, не везде так, но тенденция имеется.

3 лайка