×

Из разработки в тестирование, стоит ли?

Всем привет! Мне 26, работаю полтора года на позиции Java-разработчик, и по мнению многих, меня посещает очень странная затея, перейти с разработки на автоматизированное тестирование. Причина: перегорание, постоянные стрессы в связи реализации сложных «абстрактных» задач и дедлайнов. На данный момент тестирование для меня это прежде всего аналитика и во вторых программирование, более точная постановка задач, возможность рутины и спокойной работы.

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

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

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

А, и классы, под вашим давлением появятся, но частично (треть объектов с уникальными классами, остальное без), и будут они называться по принципу «jhdsfky80476o2ugrpi28gflwey749», и будет их целый легион. И на одной странице будет сразу несколько объектов с идентичным классом (кнопка «Add to cart» будет присутствовать и для товара, на странице которого находишься, и для каждого другого товара, который на странице упомянут в виде мелкой картинки), и вы инициируете обращение к объекту, который видите на экране, а взаимодействие произойдет с объектом, который тоже ВНЕЗАПНО есть на странице, но где-то сбоку, за видимой областью...

И с приходом нового тим-лида вы будете переползать на новые фреймворки и новые языки, и слова Геркин и Кукумбер вы будете произносить как ругательства.

А потом всё это добро надо будет ПОДДЕРЖИВАТЬ, бо через какое-то время оно будет постоянно сыпаться на пустом месте. И вы начнете потихоньку переделывать тесты, чтобы они не сыпались на пустом месте. И через какое-то время ваши тесты перестанут находить баги, или будут их находить (на пустом месте), но не там, где идет разработка, и разработчики будут ворчать, что ваши тесты столько усилий на себя тянули, а на деле не помогают.

О, как весело в автоматизации тестирования!

1.5 года ... трижды перегоревший...

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если голова не тянет абстракции — тогда в тестеры самое оно. Там едва ли попадётся, что-нибудь сложнее списка списков.

И то, список списков это еще поискать надо, как правило все заканчивается чайком на кухне

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

Впрочем, это уже уровень повыше AQA, какой-нибуть Senior SDET в солидной фирме здорового человека. Но какой, скажите мне, смысл идти в автоматизаторы, если рост остановится по тем же причинам, что и у кодера?

так если в мануал, то там и останусь наверное)

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

Особенно когда все фичи выкатывают в последние дни спринта, в итоге первую половину спринта занимал себя чем мог (доки и прочая макулатура), а потом не знаешь за что хвататься )))

Думаю вам варто спробувати написати з десяток тестів, а потім вже думати про перехід. На ютубі море курсів є Java + Selenium + NUnit. Подивіться, попробуйте, а тоді вже вирішуйте.

В теситровании тебя так же ждет

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

Это проблема не девелопмента, а твоя личная.

О дедлайнах:
1 Надо научиться ставить более менее адекватные эстимейты, это сложно очень. поэтому см пункт 2
2 Уметь внятно обьяснить почему эстимейт расширился.
3 Валить из конторые если ничего выше не помогает.

ЗЫ Ушел из автоматизации в девелопмент, ни капли не жалею.

В теситровании тебя так же ждет

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

в том и дело, эстимейты, требования это все усложняет жизнь. ))

Код ревью делают. Паттерны и архитектура есть, хотя и вариаций значительно меньше.

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

Само собой. Хотя даже девелоперы не везде делают код ревью. И качество кода бывает очень разное)

Не знаю насчет

AQA

Но я не знаю ни одного обычного укр разработчика, который прийдя на новое место, не «фаллоэмитировал» от «„качества“» уже написанного кода. И никакие юнит-тесты не помагают.

Grez, cмешно, все это есть если делать это профессионально, а не как прийдется ) лол

Хм, вообще-то есть и требования, и код ревью

У нас был проект когда и девы брались помогать делать автоматизацию, и там ревью было и все остальное. Ну там тот же DI был и многопточность и прочие штуки. Дело в том что автоматизация это не всегда селениум для UI.

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

написание кода это самая веселая и не сложная часть всего процесса.

тільки якщ що нема СІ, тестера, девопса, то код ти пишеш 5% часу,
а решта йде на вияснення ТЗ, узгоджєення, тлумачення, тестування, інтеграцію, мітинги і всяку іншу лабуду

Ну там тот же DI был

Я подобное видел, считаю что оверинджениринг, оверкилл и ненужная трата времени. Как это часто у наших разработчиков.

и многопточность

Ну если нагрузочное тестирование, то от многопоточности и не денешся.

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

Причина: перегорание, постоянные стрессы в связи реализации сложных «абстрактных» задач и дедлайнов

Попробуй отдохнуть месяца 3-6 и сменить работу

Полтора года ОР это не тот срок, чтобы говорить «я устал я ухожу».

Попробуй отдохнуть месяца 3-6

я от вас балдею — год работаем и полгода релаксируем. Иначе у бедняги перегорание, стрессы. И вооще, шо такое «перегорание»?, девочки вы не поверите, за 20 лет ни разу не поимел этого.
ТС, не нравится, уходи, и на твое место десяток желающих вайти найдется. А я тебе рекомендую попробовать себя в развитии дорог у нас в стране. Там перегорать может только асфальт, сделанный не по технологии. Стрессов там нет, голова ни чем не забитая , все просто — бери больше, кидай дальше. А усталость там только физическая — лечится соточкой и баеньки.

Там перегорать может только асфальт

Хмиль не выдержал :)

Персонально я 7 лет без отпусков и с одним выходным, до 100 рабочих часов в неделю )

И что?
Я в июне на Говерлу ходил, на следующей неделе на море собираюсь. Есть, что вспомнить

я от вас балдею — год работаем и полгода релаксируем.

Да не ниче

Ну вы же так не сможете работать до 60 лет

Без отпусков и с одним выходным? Здоровья не хватит ((

зп на гречку хватит только, а так норм

В депутаты еше ладно, но в QA??? :)

Не стоит. Будет еще больше стресса и напряга. Другое дело software engineer in test, это немного другое. это разработчик кода для тестирования какого-нибудь основного продукта. При этом сам код для тестирования может быть сложнее чем код предметной области, да и подходы могут быть нетривиальные.
Расскажу свой опыт как мы тестировали рабочую нагрузку (стресс-тест) на базу данных , для эмуляции нагрузки , создаваемой неким приложением из которого нельзя/трудно в явном виде вытащить SQL, так как оно там перемешано с кодом

1) сняли логи SQL с Оракла, во время обычно работы приложения
2) «шаблонизировали» SQL код для подстановки переменных параметров запроса
3) написали кодогенератор, который из лога SQL генерирует код (на C++, но можно на любом языке) , чтоб выполнить эти операторы sql через какой-то API типа odbc, jdbc, и тд
4) запустили сгенерированный код с разных потоков и с нескольких машин

Сам по себе тайтл software engineer in test ничего не значит, нужно знать чем предстоит заниматься (а это не всегда то что в job description написано).
Бывало что называясь автомейшном я разрабатывал более интересные решения, чем называясь SDET.

спасибо, со стороны всегда кажется что это намного проще.

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

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

А, и классы, под вашим давлением появятся, но частично (треть объектов с уникальными классами, остальное без), и будут они называться по принципу «jhdsfky80476o2ugrpi28gflwey749», и будет их целый легион. И на одной странице будет сразу несколько объектов с идентичным классом (кнопка «Add to cart» будет присутствовать и для товара, на странице которого находишься, и для каждого другого товара, который на странице упомянут в виде мелкой картинки), и вы инициируете обращение к объекту, который видите на экране, а взаимодействие произойдет с объектом, который тоже ВНЕЗАПНО есть на странице, но где-то сбоку, за видимой областью...

И с приходом нового тим-лида вы будете переползать на новые фреймворки и новые языки, и слова Геркин и Кукумбер вы будете произносить как ругательства.

А потом всё это добро надо будет ПОДДЕРЖИВАТЬ, бо через какое-то время оно будет постоянно сыпаться на пустом месте. И вы начнете потихоньку переделывать тесты, чтобы они не сыпались на пустом месте. И через какое-то время ваши тесты перестанут находить баги, или будут их находить (на пустом месте), но не там, где идет разработка, и разработчики будут ворчать, что ваши тесты столько усилий на себя тянули, а на деле не помогают.

О, как весело в автоматизации тестирования!

спасибо за ответ, я таких ньюансов не знал.

если вкратце — какая разработка (видимо убогая до немогу) такое и тестирование )

Необходимо так же упомянуть, что тестовая среда всегда будет нестабильна и Вы не сможешь опираться на результаты тестов, так как всегда какой-то из 100 сервисов не будет работать. И вы будешь дебажить это после каждого рана, потом в один момент, когда в 101 раз этот тест упадет, вы подумаете, что там опять сервис не работает, а на самом деле там БАГ и он пойдет на продакшин, конец)

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

По поводу автоматизации... У вас какие-то странные представления о ней. АТ в чистом виде (код и только код) — это небольшая часть рынка (поверьте, после java dev вы будете неприятно удивлены). Гораздо чаще нужна комбинация ручного и автоматизированного тестирования. И именно в такой последовательности.
Про рутину — это можно применить только к тому самому минимуму чистых АТ вакансий и только на старте. Писать код тестов по готовому сценарию — это уровень максимум мидла. Начиная с сеньора, от вас требуется не столько код, сколько общие инфраструктурные решения, а это не всегда просто и никогда не рутинно.
Рутинная работа в тестировании вообще возможна только там, где существуют полные и корректные требования. Если задачи «сложные и абстрактные», тестировщик вряд ли сможет жить спокойно.

Если бы вам интересно было именно автоматизированное тестирование, то смена специальности была бы разумной. Но уходить в АТ ради спокойствия и рутины — не самая удачная идея. Искомого не найдете, да ещё и рынок для себя сузите.

Ирина, большое спасибо за данный ответ, да я в поисках спокойствия и рутины :-) .

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

в мануальное тестирование это вообще фейл

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

дякую, зроблю відпустку, а далі думаю шукати нову компанію.

Думаю, абсолютно реальний варіант. Якщо не сподобається, можна і назад, або ще кудись — аналітики, менеджери, девопс. Аби подобалось. Пробуйте і діліться досвідом).

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

Сложные абстрактные задачи через 1,5 года работы — это шишки на работодателя надо кидать. Ну или расти самому, но тут таки надо выдержка.
Почему вы уверены что на том же месте работе в тестировании у вас будет более точная постановка задач и спокойная работа?

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

И еще «это менее наукоёмкое занятие», и «в тестирование идут те, кому не хватает мозгов стать программистом»...

а в менеджери, кому не хватає мозгов стать тестором, бугага

Попробуй для начала может быть сменить тип проект, сферу, команду

з девів виходять хороші AQA. В основному йдуть мануальщики, але через недостатність знань, код і підхід до задач гірші. Коли людина йде з девелопмента, то у неї хромає тест дизайн.
але якщо думаєш, що в автоматизації немає рутини — помиляєшся.

Людина навпаки хоче більше рутину і спокою(:.

саме так, але судячи з кометарїїв, в айті це не можливо.

з девів виходять хороші AQA

Нажаль не завжди. Бачив декiлька «екземплярiв» — як деви вони були крутi, а от автотести писали гiвно або занадто складний код що чорт ноги й роги переломає.

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

Хороший код пишут те, кто думает головой и кому не всё равно, как это всё будет работать и как это всё читать и поддерживать. А говнокодить могут и те и те.

моя думка про те, що коли MQA -> AQA то людина робила менший упор на вивчення програмування, код практик, патернів і фреймворків. Коли з dev -> aqa, то більше на це упор робила. Звісно воно індивідуально, але певно передумови є

А Ви думаєте в тестуванні такого нема? Думаєте що не буває коли за 3 дні кидають на три різні таски бо клієнт вконтре змінив пріоритет. Це я говорю з сторони AQA. Все залежить від фірми та проекту.

я просто дивлюсь на своїх коллег тестувальників, і ніколи не бачив таких запар, що мае наша команда девів.

Це в вас якось не стандартно. Майже завжди, деви ще можуть підзатримати код, а вот тестування від цього тільки зжимається в часі, а ніяк не в об’ємі роботи, і тоді в режимі «реліз завтра за сьогодні швиденько тестуємо» працюють аж гай гуде.

Потолок зарплат у Senior Auto QA и Senior Dev все-таки весьма отличается.
А так, why not. Всегда можно вернуться.

Судя по опросу — до 15 %. В реальности qa авто могут больше девов получать.

В реальности они не то что могут, они получают.

Но, нужно уметь.

з QA легше йти в менеджери,
а можна і в девопси....
одним словом «пробуй»...

девопси теж цікаво, але треба більши досвіду мабуть.

1.5 года ... трижды перегоревший...

Не смешно. Бывают такие обстоятельства, что и за год человек может сгореть.

Печально, но да. Может быть даже и полгода... Зависит от человека и проекта.

Какие мы нежные ©

Это означает лишь то, что это случайный человек не на своём месте.

И как это противоречит тому факту, что он перегорел от такой работы?
Да, очевидно, что он не на своём месте, раз до такого дошло. Возможно, раньше он был на своём (и не был «случайным»), а потом что-то поменялось на проекте или в команде. Всякое бывает.

И как это противоречит тому факту, что он перегорел от такой работы?

И хочет те же яйца, только в профиль? Ну-ну.

Возможно, раньше он был на своём (и не был «случайным»), а потом что-то поменялось на проекте или в команде.

Это и называется не на своём.

Согласен с вами, наверное я не на своем месте, а что делать, в Польшу разнорабочим ехать?

Можно к гадалке сходить — она 100% знает.

та вот был недавно, сказала вы знаете что делать.

Контору смени, как тебе выше писали, да и всё

можливо, означає, що занадто переймався

Так сильно волновался, что кушать не мог? :)

Это очень годный вариант.

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