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

Уйти из программирование в QA

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Добрый день.
Планирую уйти из программирования ( PHP, JS, Yii, Symfony 2, etc ) в QA, желательно Automation.
Кто что скажет полезного на эту тему?
Планирую пройти онлайн-курсы, изучить Selenium и JMeter.

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

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

Одобряю!
И дальнейший карьерный рост: Automation QA -> Manual QA -> Кассир в Сильпо -> релокейт в деревню.

Грустно до сих пор видеть в комментариях такое несправедливое отношение к тестировщикам, а ведь на самом деле QA Automation, как по мне, такая же интересная специальность как и разработчик. В свое время мне предлагали перейти на Scala/Java разработчика, но я отказался. Попытаюсь объяснить причину.
В нашей компании мы пытаемся автоматизировать все что только сможем. В конечном итоге цель у нас простая — делать релиз один раз в день. А для этого нужно иметь стабильную систему тестов/билдов/деплоймента так как весь пекедж состоит из большого числа сервисов. Могу привести мой список деятельности на проектах:

  • Написание автотестов на Scala, JavaScript, Ruby. В проектах используется Selenium, Calabash, Gatling, JMeter.
  • Поддержка существующего пайплайна. Приходится очень много ковырятся в Jenkins. Также приходилось разворачивать пайплайн для отдельного проекта.
  • Разработка моков в (Scala, Play Framework).
  • Разработка систем мониторинга, отчетов и управлением пайплайном (Scala, Play Framework, MySQL). К сожалению не могу дать ссылку на проект, пока что не было времени пройти через нашу бюрократию и вывести его в опен-соурс.
  • Исследование и разработка новых методов тестирования (Galen Framework)
В итоге приходится очень много писать на Scala, Java, Python, Bash, JavaScript и изредка в Ruby и постоянно переключатся в разные проекты. В своей работе я могу побыть немножко и разработчиком, и проджект-менеджером, и дев-опсом, и тестировщиком, и дизайнером. И это очень даже интересно.

Переходи, почему бы и нет? Технически грамотный, хороший QA на проекте ценее немотивированного, уставшего, программиста.
ИМХО, быть одним из лучших среди QA это гораздо лучше чем среднячком среди программистов.

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

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

стоит — если с прицелом потом перейти в PM-ы
QA обычно хорошо секут в жизненном цикле проекта, поэтому из них МОГУТ получиться лучшие менеджеры.

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

Я думаю, что по факту уровень программирования в QA (даже Automation) такой же как уровень программирования у Системного администратора.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Я не понимаю зачем уходить в КуА, программист не то что может, он должен писать авто тесты на свой код

Мда, сколько же батхерда может вызвать подобная тема)
Боюсь предстваить что же думают о девах которые переходят в QA Manual...
Печально это ребята)

Automatic
Это реально мило :) Круче только «Пистолетик» или «Пушечка» :D

чего на человека все так накинулись?
я вот знал одного чувака — он ужел в performance testing — ну так там более чем интересно( как по мне прикольнее чем имплеиентить бизнес кейсы как бешеная макака)

да ладно
ковырятся в тоннах дкода пытаясь осознать истинный дзен каждого ифчика не менее интересно)

performance и stress testing это вообще тема интересная, и там навыки программирования еще как нужны. я как-то писал нагрузочный тест для оракла с помощью самописного кодогенератора который генерировал текст на c++ из sql скриптов :-)

я когда то на akka тул для тестирования пилил например, более чем интересно

А кто-нибудь вообще задумывался над фразой QA automation? Это же оксюморон.

видимо Вы мануальщик ))))

Все истинные тестировщики — мануальщики, потому что знают, что автоматизация это не тестирование.

Это только потому, что не понимают разницу между тестированием и QA.

скорее просто не умеют кодить )

Тестировщику не нужно уметь кодить. Поинтересуйтесь у Баха что такое тестирование, а что такое автоматизация, и в чём отличие testing и checking.

Ну если Википедия это ваш аргумент в противовес мнению таких профессионалов как Бах, Канер, Болтон, то мне с вами не о чем дискутировать, простите :)

ну я могу привести в качестве источника ISTQB или это то же не авторитет ))))?
зайдите на досуге на www.istqb.org и внимательно на схемку посмотрите )

Покажите, где ISTQB даёт определения тестированию, автоматизации и объясняет разницу между ними? То, что вы на схеме увидели слово automation, ещё ничего не значит.

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

Всё понятно. Вам незнакомы ни имена, которые я выше приводил, ни то, о чём эти люди пишут много лет. Дискуссию вести считаю невозможным в виду пребывания собеседника вне контекста :)

Вставлю свои пять копеек.

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

Они говорят, что пользователь не ведет себя как заскриптованый NPC.

Грубый пример, между шагом 1 и шагом 2, пользователь может пойти кофе заварить, если шаг 1 это запросить печать отчета, а 2 — проверить, что он распечатался. Пользователь пришел, забыл что печатал и отправил еще раз на печать и потом кричит, что напечаталось два отчета вместо одного. Утрирую для примера.

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

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

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

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

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

Забавно что девелоперы никогда не спорят между собой о своем тайтле. Это прерогатива только QA или тестеров, вы уж разберитесь как там правильно :-)

Не могу молча пройти мимо вопиющей подмены понятий — QA/тестирование/автоматизация :)
Ладно бы это ещё какая-нибудь малолетняя рекрутерша такое допускала, но когда так делают коллеги, то это очень огорчает.

А есть какая-нибудь авторитетная ссылка кроме википедии, которая поясняет чем же в идеале занимается QA? потому что каждый QA поясняет как-то по-своему и на слово тестер обижается, хотя вот например вполне приличные вакансии: jobs-gojbm.icims.com/...sRedirect=false или тут:
jobview.monster.com/...x?jobPosition=2

Если коротко, то можно почитать тут reinderotter.blogspot.com/...de-in-same.html

Не знаю насколько авторитетно. Просто если лазить и искать подтверждение, то найдем тоже самое, что и в статье:

“Quality Assurance is process oriented and focuses on defect prevention, while quality control is product oriented and focuses on defect identification. as is stated in an article on Diffen.”

У девелоперов просто нет тайлов «кодер» :)

А вот здесь вы не угадали :). Я встречал спор программистов о том, кого называть кодером, а кого — программером. Так вот, кодерами предлагали называть тех, кто занимается собственно кодированием, а не полным процессом разработки ПО. А по второму варианту, кодерами предлагалось называть тех, кто занимается очень низкоуровневым программированием.

А кого называть говнокодером?

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

На уровне обсуждений — быть может, но вот в тайтлах встречать не приходилось (а речь шла именно о них).

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

Вроде как не о тайтлах спорят.
К тому же вы говорите «девелопер», в профиле у вас написано Software Engineer, кто-то скажет «программист», а иной «кодером» обзовет )
Неопределенности на всех хватит

В том то и соль, что это все одно и тоже и мне например лавры «начальника шлагбаума» не нужны. Можно классифицировать стол как черный и белый или деревянный vs металлический, но стол есть стол. Также и кодер. Кодер даже лучше, чем «программист в ПриватБанке».

А чем плохо быть программистом в Приватбанке?

Все в мире относительно. Люди, подверженные синдрому «начальника шлагбаума», ведутся на громкие названия, даже если за ними стоит по сути одно и тоже и деньги те же. Этот нонсенс я и пытаюсь подчеркнуть.

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

Возможно он и устарел, но, к примеру книга Lessons Learned in Software Testing, соавтором которой он является, это 100% маст-рид для любого тестировщика. Несмотря на её возраст (14 лет!), актуальности она совсем не утратила и содержит море полезной информации. Более того, другим её соавтором является всё тот же Бах, а его вполне современная контекстно-зависимая школа тестирования это как раз вызов консерватизму в тестировании.
Что касается сертификаций типа ISTQB, нужно понимать, что это в первую очередь способ зарабатывания бабла вплоть до «пока не сертифицируешься, работу не получишь» в некоторых западных компаниях. У Баха и Болтона есть ряд публикаций на тему ISTQB, где они рассказывают почему подобные сертификации вредят индустрии тестирования, и почему черпать знания из подобных источников — плохо для развития. Вот и получается, что начитавшись таких сертификаций и не понимая что к чему, не разобравшись в определениях, человек называет автоматизацию частным видом тестирования :)

Вообще вылетело из головы название. И наверное я Баха зря туда записал ) Эх память

Найду — скажу )

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

Может кто вспомнит. А я потом дома порыскаю по закладкам и истории.

Таки да, все перепутал. Автор Канер и это крусы.

Black Box Software Testing course

Please Note: BBST is a Registered Trademark of Kaner, Fiedler & Associates.

У вас каждый последующий источник фееричнее предыдущего :D

ну я Вам привел несколько источников похоже Вам уже не поможет )

Вы не поняли сути первоначального спора. Дело не в классификации, а в сущности тестирования и автоматизации, в их кардинальной разнице:
www.developsense.com/...9/08/testing-vs-checking

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

Это не заслуга сертификации, и уж точно не её цель.
Разобраться с материалом поможет толковая книга или лекции какого-нибудь признанного в тестировании гуру. В частности, для изучения техник за 10+ лет ничего лучше не написано, чем книга Коупленда A Practitioner’s Guide to Software Test Design. Ну а английский подтянуть можно с помощью чего угодно, не прибегая к дорогой и бессмысленной сертификации.

Вот такое меня просто убило «К анализу идей привлекаются специалисты по маркетингу, руководители проекта, главные конструкторы и специалисты по анализу человеческого фактора»

Мысль здравая.

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

я не об этом)))) вот сколько работаю в IT и ни разу в глаза не видела

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

Потенциально да.

Не уверен, что недоинтерны до того места дочитывают.

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

Quality Assurance подразумевает в том числе и разработку и внедрение процессов направленых на улучшение качества кода. Таким образом без навыков програмирования настоящим QA не стать.

Например в Microsoft и некоторых других компаниях это называется Software Development Engineer in Test

а можно поинтересоваться, сколько вы в данной области?

Лучше назовите годовой инкам.

«А может тебе ещё дать ключ от квартиры, где деньги лежат?» ©

Опаньки, однофамилец :-)

Грустно до сих пор видеть в комментариях такое несправедливое отношение к тестировщикам, а ведь на самом деле QA Automation, как по мне, такая же интересная специальность как и разработчик. В свое время мне предлагали перейти на Scala/Java разработчика, но я отказался. Попытаюсь объяснить причину.
В нашей компании мы пытаемся автоматизировать все что только сможем. В конечном итоге цель у нас простая — делать релиз один раз в день. А для этого нужно иметь стабильную систему тестов/билдов/деплоймента так как весь пекедж состоит из большого числа сервисов. Могу привести мой список деятельности на проектах:

  • Написание автотестов на Scala, JavaScript, Ruby. В проектах используется Selenium, Calabash, Gatling, JMeter.
  • Поддержка существующего пайплайна. Приходится очень много ковырятся в Jenkins. Также приходилось разворачивать пайплайн для отдельного проекта.
  • Разработка моков в (Scala, Play Framework).
  • Разработка систем мониторинга, отчетов и управлением пайплайном (Scala, Play Framework, MySQL). К сожалению не могу дать ссылку на проект, пока что не было времени пройти через нашу бюрократию и вывести его в опен-соурс.
  • Исследование и разработка новых методов тестирования (Galen Framework)
В итоге приходится очень много писать на Scala, Java, Python, Bash, JavaScript и изредка в Ruby и постоянно переключатся в разные проекты. В своей работе я могу побыть немножко и разработчиком, и проджект-менеджером, и дев-опсом, и тестировщиком, и дизайнером. И это очень даже интересно.

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

програмисты с этим тоже збс справляются, проверенно

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

я аналогичный выбор сделал — из разработчика в QA

Активно использую Selenium WebDriver + Junit в автоматизации

спрос на QA automatization очень большой и тут и за рубежом

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

выбором своим доволен )

Можеnt объяснить почему вы сделали такой выбор? Как я узнал из вашего профиля,вы ранее работали фронт-энд девом,там ведь тоже разнообразия хватает,можно работать с чистым JS,писать на ангуляре,верстать страницы,в ХТМЛ5 гейм дев уйти,уйти потом в фуллстэк,ну вообщем хватает.
Я сейчас уже 2 года работаю тестировщиком и хотел бы во фронт-энд перейти и не знаю стоит ли.

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

QA automatization
работа более разнообразная чем узкоспециализированный девелопмент
патсталом

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

сейчас программисты возмутятся )

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

это не утопия, а необходимость

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

в смысле? разработчики не должны писать юнит тесты?

я прямо сейчас работаю в такой компании, точнее на таком проекте. Правда от этой практики сейчас уходят

не скажите, почему уходите от этого?

ну уходим от написания юи тестов. ЮИ занимается отдельная команда. Наверно потому что разработчики не любят писать юи тесты :) Плюс решили что тестеры все таки нужны

Может человеку разнообразия захотелось. Когда каждый рабочий день из разряда «I hate my job», то никакая зп не утешит. Не вижу ничего необычного в переходе из дева в QA Automation. Вот если бы в мануал — тогда да, странновато было бы))

Можно подумать в программинге меньше разнообразия чем в «qa automation».

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

Та да, программисты на джаве суперограничены: bigdata, ai, machine learning, high load, любой вебдев, андроид.
А чем там qa automation занимается при тестировании дров?

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

Я у своего парня-джависта спросила, какие проекты на джаве ему нравятся. Он ответил, что никакие.
НУ это проблемы фригидности твоего парня-джависта.
Нужно разбираться не только в той софтине, которую автомейтишь, а и в недрях ОС и железе.
Ну тогда у абстрактного qa automation шансы попасть на такой проект не больше чем у джависта.
НУ это проблемы фригидности твоего парня-джависта.
это проблема, с которой может столкнуться каждый, кто писал на одном и том же ЯП в течении 10 лет

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

что-то я не заметила чтобы он парился из-за этого))

По поводу фригидности? Ну так это обьяснимо.

а что случилось то ? всем интерестно зачем человуку в QA.

Да вброс какой-то.

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

Все правильно. Приелось и пока не хочется.
Смежную ветку вижу или QA, или PM.

Автор, никогда по пьяни не звоните бывшим и не создавайте тем на доу.

Да вижу, 45 коментов г-на. Как-то не впечатляет доу.
Вместо *конкретных* советов. В принципе, предыдущий опыт общения русс/укр форумов этим и заканчиваются, в отличии от западных.

Это уже 100 раз здесь проскакивало, но тем не менее:
Чем отличаются американский, еврейский и русский форумы?
На американском форуме ты задаёшь вопрос, потом тебе дают ответ.
На еврейском форуме ты задаёшь вопрос, потом тебе задают вопрос.
На русском форуме ты задаёшь вопрос и потом тебе долго объясняют, какой же ты м*дак.

Если бы написали что хотите стать автоматизатором и имеете навыки программирования, то было бы иначе. А так само название темы задало контекст беседы. Каков вопрос...

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

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Существует мнение, что программист сможет тестировать лучше, чем QA в силу того, что у программиста есть опыт разработки.

и нет опыта тестирования )

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

поверьте мне, что это большое заблуждение)

Аргументируйте. Любой разработчик тестирует свой функционал. В моем опыте было такое, что я находил баги, о которых QA и не подозревали просто в силу того, что не понимали, как технически работало то, что они уже протестировали.

Разработчики проводят в оновном дев тестинг. Они не владеют разными техниками тетстирования, они могут реально не знать или упустить взаимосвязи между модулями в приложении. Были конечно и случаи, о которых вы упоминули. Ну я еще не встречал ни одного супер-пупер программиста, у которого я или мои коллеги не находили дефекты просле имплементации.

Вы никогда не думали, что у программиста времени для того, чтобы протестировать свою же имплементацию меньше, чем у QA? И в этом есть смысл. А теперь представим, что у программиста есть столько же времени. Тогда он находит и баги, о которых упомянул я и все остальные. Думаю, для человека с девелоперским бекграундом освоить разные техники тестирования не будет проблемой.

меньше, чем у QA?
Это полное заблуждение. А QA типа нечем заняться.
Думаю, для человека с девелоперским бекграундом освоить разные техники тестирования не будет проблемой.
Так почему не осваивают?

Что значит нечем заняться? QA тестируют. Суть в том, что дешевле нанять QA, чтобы он тестировал, чем платить за тестирование разработчику.
Не осваивают, потому что в этом нету необходимости.

Все гораздо проще, скорее всего человеку надоело писать сайты на PHP на фрилансе. Но почему перейти в QA? Наверное многие склонны считать, что это самый быстрый «вход» в IT.

Переходи, почему бы и нет? Технически грамотный, хороший QA на проекте ценее немотивированного, уставшего, программиста.
ИМХО, быть одним из лучших среди QA это гораздо лучше чем среднячком среди программистов.

Что автор, «синдром эмоционального выгорания», да?

толстовато

Одобряю!
И дальнейший карьерный рост: Automation QA -> Manual QA -> Кассир в Сильпо -> релокейт в деревню.

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

вы ржете а automation qa мало и на них есть спрос
ну так автор інше шукає
QA, желательно Automatic
Automatic
...

автор php разработчик, «automatic» поправимо со временем

Вы занимались разроботкой сугубо в целях подзаработать больше? Так если так, то начинайте писать на Java/Scala, ЗП большие, точно больше чем у QA и даже Automation :D

Ясно что у Java/Scala сениора зарплата больше чем у qa automation. Только при одинаковых временных затратах карьерный рост такой
java junior = qa automation
java middle = qa automation lead
java/scala senior = qa vp
и чем дальше тем больше отличается зарплата не в пользу Java/Scala синьора

qa vp это что? разве есть что-то после лида на этой ветке?

Кому то надо и трамваи водить ©

Automatic
с англ точно все ок?

Автор, вы что-то нереальное говорите) Не бывает такого)
Вы точно программист или просто побаловались немного и не понравилось?
Объясните как так вышло :)

Уйти из программирование в QA
це те саме, що «живу» дівчину проміняти на гумову бабу

«И все-то вы знаете, и везде-то вы побывали...» ©

Печальный у вас опыт, если так сравниваете.

может тогда в мобильное тестирование уйти ? calabash, appium ?

зазвичай навпаки QA -> QA Automation -> Dev...

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

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