Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Из Python Developer’a в Automation QA. Стоит ли?

Всем привет.

Работаю Python Developer’ом полгода. Последний месяц все больше наблюдаю за работой колег в Automation QA и думаю, что это больше мне по душе, чем разработка.

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

В первую очередь интересует не жалеете ли об таком выборе, какие + и — можете выделить такого перехода и насколько большая разница в зп?

Дополнительно, хочу спросить: что нужно подучить для такого перехода?

Знания Python’а довольно неплохие. Есть минимальный опыт работы с Selenium Webdriver и модули unittests/PyTest.

👍ПодобаєтьсяСподобалось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

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

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

Разницы в зарплате не было.

Возможно, стоит развиваться, как SDET, если разработку вам не хочется бросать? Их довольно мало на рынке Украины, в Америке чаще встречаются.
Платят за такую роль не меньше, чем разработчикам.

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

Какие плюсы:
1. Скорее всего в development части ты будешь сильнее своих коллег, соответственно сможешь получать более интересные таски и делать их легче/быстрее чем ожидается.
2. Побываешь по ту сторону баррикад. Облегчает понимание противоположной стороны
3. В общем и целом это легче, чем программирование в чистом виде. Зачастую норм библиотек для автоматизации не так и много и они похожи и просты для изучения. По сравнению с девелопментом, коненчо)
4. Исходя из пункта 1 и 3 меньше конкуренция для тебя персонально.

Минусы:
1. Меньше зп. Но если у тебя нормальные developer-скиллы, то ненамного, а то и такая же будет. Потому что зачастую на проект нужен хотя бы один человек, кто может нормально кодить
2. Нужно разобраться с теорией тестирования. Как минимум для прохождения собеседования, но и для повседневной работы. В первом случае возникает такая проблема, как нечеткие термины. Часто можно встретить ситуацию когда одним и тем же словом, называют три разные вещи на трёх разных проектах. Есть некий стандарт ISTQB, но на практике от него часты отклонения.
3. 100% автоматизация встречается не так часто. Бывет, что сгружают мануальщину на 20-50%. Если это для тебя неприемлемо, это нужно сразу проговаривать
4. Если фреймворк и продукт написаны хорошо, то львиная часть работы становится отупляюще легкой.

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

Знаю лично 2 таких кейса. Никаких проблем с этим не вижу. Единственное, что: рекомендую подучить процессы, чтобы работать не «разработчиком тестов», а AQA инженером. Позволит проще найти работу в будущем.
ISTQB basic level тебе в помощь)))

Є два типа AQA :
— перші пішли — рік працювали девом -> свічнулись в AQA.
плюси — пишуть хороший код, проробляють архітектуру, легко вивчають нові фреймворки\тулзи
мінуси — пишуть так собі тести, беруть мало участі в проекті як QA(мітинги, аналіз вимог, etc)

-вид № 2 — були мануальщиками -> трохи подивились курси по програмуванню -> свічнулись в AQA
плюси — краще розбираються в QA частині, тести проектують згідно різних технік та бізнес флову
мінуси — пишуть хреновий код, часто ліниві, щоб вивчити щось нове

Обидва види канонічні. Взагальному, залежить від людини і її бажань та цілей.
Якщо є бажання свічнутись, окрім знань пайтона та вебдрайвера почитай ще про тестування\техніки тест дизайну

У вас оба типа какие-то ущербные. Первые плохо пишут тест-кейсы, вторые — код.
Это умозрительное заключение: «так было бы логично»? Или у вас обширный опыт код ревью?
Придираюсь потому что мой опыт говорит о другом. Абсолютное большинство автоматизаторов — бывшие Manual QA. Кто изначально техничен и заинтересован — уходит глубоко в автоматизацию и пишет хороший код.
Из многих десятков автоматизаторов, которых знаю лично сейчас вспомнил только троих, которые перешли из девелопмента.

Взагальному, залежить від людини і її бажань та цілей.

Написав виходячи з досвіду. Є багато людей, яким цікаво і дійсно стають хорошими AQA. Бувають, що ні. На мою думку, це через те, що зразу велика к-сть MQA не дуже технічна

Читал много кейсов, когда люди начинали с AQA, а потом переходии в разработку. Но обратной об обратной ситуации ниразу не читал

С обратных ситуаций все и начиналось, то вы плохо искали)

насколько большая разница в зп?

Хороший AQA в половину больше зарабатывает питониста. Плохой в половину меньше. )
Другими словами зп зависит от вас а не от направления.

Перспективы долгоиграющие. А если более детально — поле непаханное. Тут не 5 копеек заработать, тут можно найти свое направление и построить на нем хорошую карьеру.

Если реально прёт, то стоит переходить полюбому ! Я ранее работал на Xamarin, всю жизнь его ненавидел и тут как-то перешел в UWP который мне очень нравится и блин я счастлив теперь, иду на работу как на праздник !

Работаю на ксамарин, хочу спросить сильно ли отличается uwp от xamarin и от wpf?

Работаю ксамаринщиком, все нравится, но хотел спросить: много ли работы для uwp?

вот не встречала еще профили дотнетчиков, использующих UWP, просто очень интересно взглянуть на ваш профиль :)

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