Check Levi9 best QA positions to Backbase team!
×Закрыть

Помогите сделать правильный выбор — QA or Development

Здравствуйте!

Предложили роботу джуна-тестировщика(manual) в компании занимающейся разработкой веб-сайтов (сейчас учусь в ШАГе на разработке программного обеспечения и в перспективе 1-2 года вижу себя девелопером(С#, Java, PHP/JS) и параллельно работаю в сфере не связанной с ІТ).

Смена работы повлечет за собой:
+ опыт в ІТ
— уменьшение оплаты труда
— отсутствие свободного времени для самообучения программированию
— переезд в другой город

И вот именно вопросы:
1. Как воспримут потенциальные работодатели опыт тестировщика, в случае начала карьеры разработчика ПО в будущем?
2. Смогу ли я получить в процессе работы тестировщиком, знания и навыки, которые мне пригодятся в разработке ПО?
3. Нужно ли мне тратить время на глубокое освоение области тестирования или направить все усилия на изучение программирования?
4. На сколько сильно связанны — автоматизация тестирования и программирование(и в чем)?

Буду рад обоснованным советам!
Заранее благодарю!

👍НравитсяПонравилось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

Разве тестировщики существуют? Я работал много лет в разработке сайтов и ни одного не видел.
Зачем они?

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

Все, кто ели огурцы — умерли.
Следовательно, огурцы смертельно ядовиты.

Прошу развеять/подтвердить, опираясь на собственный опыт:
1. Программистом может стать любой человек, если очень захотеть и приложить максимум усилий.
2. Java — тяжелый в изучении и по-этому не подходит в роли первого языка программирования для новичка. Лучше начать с С#

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

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

1. Нет
2. Если Java как просто язык — то все равно, что Java, C# и т.д. Проблема в том, что просто знания синтаксиса языка недостаточно. Нужно знать большой зоопарк разных технологий которые идут вместе с языком. И тут если нету базовых пониманий определённых вещей то что С# что Java — будет одинаково сложно.

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

1. Нет, даже пытаться не стоит. Стать врограммистом в одиночку — практически нереально.
2. Лучше не начинать.

А вдруг человек поверит тебе и не поймет, что шутка?

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

1. Программистом может стать любой человек, если очень захотеть и приложить максимум усилий.
Нет.
2. Java — тяжелый в изучении и по-этому не подходит в роли первого языка программирования для новичка. Лучше начать с С#
Нет, все языки подобны, если говорить об их знании, а не умении написать хеллоуворлд.
Язык выбирать следует из области, которую может понравиться программировать.

1. Да. Какихто особых ген или дара не требуется (во преки всем остальным отписавшимся). Другое дело что без задатков логического и абстрактного мышления, а также готовности искать, сортировать и анализировать большой объем информации, сделать это будет крайне тяжело. Впрочем, и такие ребята встречаются, так что все возможно!
2. Сишарп проще только тем, что основные различные технологии поставляются майкрософтом из коробки, достаточно установить сам дот нет и вижл студию, и можна работать. В случае с джавой нужно самостоятельно скачать/установить/настроить кучу всего, эдакий конструктор, далеко не эллементарный. Сами же языки — примерно одинаковые. И в текущем времени порог вхождения считается не самым простым, но и далеко не самым сложным.

Для начала IDEA Community Edition будет достаточно будет более чем достаточно, один установочный файл

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

Джава там идет в комлекте, ничего отдельно ставить не надо. Вообщем то с веб апликейш тоже проблем нету. Community Edition поддерживает Maven создаем проект под мавеном вткыкаем в pom.xml jetty-maven-plugin. И все веб апликейшн поднимается за пол секи. Мне лично хоть компания и купила ИДЕЮ я все делаю через мавен, ИДЕЮ только использую как редактор

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

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

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

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

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

Все равно не вижу проблем, я не стесняюсь гуглить для незнакомых и подзабытых вещей «how to set up...», а мои знакомые senior-ы делают это еще больше и чаще. Почему бы юным падаванам не приобщаться к полезной привычке? День-два помучается зато потом уже будет точно знать где и что настраивать.

Что Java что Maven настраивается в 3-4 клика + переменные окружения, сервак выбирается в зависимости от примера.

Три дня гуглить как запустить чертов сервер, и собственно программирование — разные вещи.
Встречал не одного человека, которые это дело на этапе «изучения» забрасывали, и переходили куданить в дот нет, или руби.

так это же хорошо, значит в Java будут по-прежнему высокие зарплаты. Я в свое время 4 дня изучал мавен, но пересилил себя.

Мавен настравивать и качать не нужно, идет бандлом в ИДЕе. Когда создаем проект выбираем Maven Project готово. Там будет лежать pom.xml в него вставляем например

org.eclipse.jetty
jetty-maven-plugin
9.2.11-SNAPSHOT

с права в ИДЕЕ будет видна панелька с кнопкой Maven нажимаем открылось меню в нем открываем plugins и дальше jetty run.

Сам мавен подтянет jetty и запустит проект.То есть опять же вручную качать кроме идеи ничего не нужно будет.

Я понимаю что оно не очевидно, но скажем так на пути программиста это елементарные вещи.

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

Это конечно хорошо, что они по правильному пути идут.

не знаю, как насчет любого — но вживую я сейчас наблюдаю ситуацию, когда люди без какого либо технического бекграунда, вгрызаясь в учебу 24/7(книги, курсера) обгоняют по всем позициям тех, у кого есть даже техническое образование и какой-то опыт.
Начните с python.

Нужны специфические тараканы в голове

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

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

2. Java — тяжелый в изучении и по-этому не подходит в роли первого языка программирования для новичка. Лучше начать с С#

По моему в качестве первого языка программирования очень хорош Python.

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

Вот только не надо про способности. Большинство сегодняшних программистов не освоят на нормальном уровне обычную рабочую профессию.

Из первой строки я вижу «Однозначно нет», а из следующих, что да, но потолка в специализации достичь не получится (гугл, тесла, что-то ещё) и писать будешь медленнее. А в какой профессии не так? Какое-то у тебя Однозначно неоднозначное.
Я не вижу ничего плохо в работяге-инженере, потолок которого будет 1-2к. И работы для такого работяги немеренно. В нашей стране это всяко лучше, чем инженере на заводе или под землёй с потолком в 500.

я вижу «Однозначно нет», а из следующих, что да, но потолка в специализации достичь не получится

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

Я немало занимался обучением программированию — попадались те кто даже основы HTML и CSS со скрипом осваивают, простейшие истины им нужно раза три объяснить чтоб что-то на эту тему смогли написать самостоятельно. И это не программирование, и даже не относительно сложные разделы CSS.

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

о, уже что-то новое, не из серии «Как стать тестировщиком». Уже джуны рассматривают и вариант педалить

У толковых джунов всегда были варианты.

Если такой вопрос встал, то однозначно в QA ))

Всем большое спасибо за советы! Сегодня я принял решение, а завтра откажусь от предложенной вакансии — буду растить в себе ДЕВА!
В продолжении темы(вижу присутствие опытных разработчиков) — подскажите пожалуйста краткий алгоритм — в каком порядке изучать и с каких технологий рекомендуете начать.
Пока изучаю С++ и ООП, далее в программе — джаваскрипт(+хтмл+цсс) паралельно PHP, далее C#, .Net, Java.
Может есть какой-то другой коктейль успеха?
И кстати — я так и не понял — чем конкретно ШАГ так плох — ну выдает ничем не подтвержденные дипломы всем — лишь бы деньги за обучение платили... и что... мне например пока попадались действительно толковые преподаватели, лишь бы хотел учиться...

Пока изучаю С++ и ООП, далее в программе — джаваскрипт(+хтмл+цсс) паралельно PHP, далее C#, .Net, Java.
Вы хотите знать «почти ничего почти обо всем»? :)

Согласен — все будет так, как Вы и написали, по-этому и прошу задать мне правильный вектор движения. Просто я еще не понял — какой технологии отдать предпочтение — ПХП вроде как полегче, С# .Net — входит в тренд, Джава — еще перспективнее...

Тренды все эти — ерунда полная. Цель-то какая у вас?

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

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

Если вы в самом начале пути, то изучать не 100500 технологий, а матчасть: алгоритмы, паттерны, сети если в веб планируете идти и т.п... Дальше определиться с тем, что все-таки привлекает больше всего(веб, моб., ...) и изучать что-то одно. Какую бы платформу или язык вы не выбрали (исключая откровенную экзотику) — работа найдется. Просто если единственной вашей целью будет «большая зарплата» (пока, простите, такое впечатление), то получить эту первую работу будет ох как непросто.

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

Человек же сказал, что учится в ШАГе. Это их учебная программа такая, а не его придумка.

Классно студиозусов на бабки разводят.

Ну сорри тогда, такая версия мне в голову не приходила. Мне сложно представить себе, чему можно научить(ся) при таком подходе. Уж лучше самому, чем по такой бессистемной программе, имхо...

Пишешь на бумажечках «джаваскрипт(+хтмл+цсс) + PHP, C# + .Net, Java, а также Обджектив-С, Ондроед-который-тоже-почти-джава, Руби, Питон, вотевер», соваешь в мешочек, тащишь одну — и вперед!

... тащищь одну — а там «Бажаємо виграти наступного разу» :)

интересует: веб-разработка, разработка приложений под мобильные устройства, ПО под бизнес-задачи).
Вам джаву сам Бог велел.
буду растить в себе ДЕВА!
може не варто?
uk.wikipedia.org/wiki/Деви
краткий алгоритм — в каком порядке изучать и с каких технологий рекомендуете начать.
щось таке для початку:
www.coursera.org/...fundamentalscomputing2/37
www.coursera.org/...alization/cybersecurity/7

www.coursera.org/course/algs4partI
www.coursera.org/course/algs4partII
www.coursera.org/course/hciucsd
www.coursera.org/course/comnetworks
www.coursera.org/learn/internet-history
www.coursera.org/course/webapplications
www.coursera.org/course/db

www.coursera.org/...mancomputerinteraction/28
www.coursera.org/...ization/cloudcomputing/19

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

це так, для початку, а потім можна говорити про ріст вашого «дева»...
ну а хочете стати простим манкі-кодером — то вперед, любу книжку «ххх[Java|c#|php|python|ruby] за 21 день», але перехід на мідла вам не так просто дасться, а з мідла перелізти вище — ще гірше.. ну і в умовах коли «джуніорів» на порядки більше ніж вакансій під них,ті самі згадані курси в резюме зайві не будуть ;)

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

Пока изучаю С++ и ООП, далее в программе — джаваскрипт(+хтмл+цсс) паралельно PHP, далее C#, .Net, Java.
Жуть.

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

Как бл#дь можно определится с тем, что тебе нравится, не попробовав это сначала на практике? Человек же сказал — он учится в академии ШАГ, это их учебный план, обучение всему этому занимает 2.5 года, в чем тут жуть-то?

Ну тогда челу и жизни не хватит на все выше. Один С++ за 5 лет только чуть понимать начнешь. Я уже более 20 в нем и то избегаю всяких навороченных вещей. Стараюсь писать попроще.
А знать сразу и все не возможно, тем более за 2.5 года.
В NET, Java спецами становятся тоже только минимум после лет 7.

А как

бл#дь можно определится
просто выбрать направление. У каждого языка выше своя область применения. Вот и определиться с областью.
В NET, Java спецами становятся тоже только минимум после лет 7.
«спец» це поняття сильно змінне, завжди будуть люди круче за тебе, і більші ламери теж ...

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

синьйор-billable-теннисист вполне, но до уровня seniority там далеко.

Глупое решение. Девом вам никто не предлагает стать, да и в перспективе может не получишь больше предложений стать QA. Толковый QA всяко ближе к деву, чем продавец-консультант из Зары, у меня куча примеров, как люди из QA становились девами.

потому что ШАГ это выкачивание бабла из лохов. Учится необходимо самому. Для старта можно использовать 1-2 модуля каких-нибудь курсов и все.

Конечно в Dev! Ну зачем Вам это тестирование, если видите себя через пару лет девом !? Поменять разработку на какие то тест планы, тест кейсы?

В Штатах сейчас отмирает black box тестирование (мануальщики). Сейчас большинство переучиваются на автоматизаторов, но требования к ним зачастую не ниже, чем к девелоперам. Подозреваю лет через 3-5 эта волна дойдет и до Украины. Если есть возможность учиться на разработчика и это нравится — думаю что правильнее будет продолжать.

кстати — дбильная «волна». Автоматизатор — не мануальщик; отсуствия звена, которое валидирует спеку, делает блекбокс, и быструю регресию по фичам — печаль. Имхо.

а тут немного не так. Просто QA должен быть автоматизатором, но при необходимости делать и black box.

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

QA умер. нет я не оговорился он не умирает а умер. Он еще немного бьется в смертных конвульсиях но он умер.

Прежде чем бить меня ногами — я около 25 лет проработал в QA. От простого тестировщика до automation до VP of QA до VP of Engineering который руководил и QA.

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

Друзья, позаботьтесь о своем будущем.

С радостью отвечу на вопросы а может как то и напишу статью как поменялось QA за последние 10 лет.

напишу статью как поменялось QA за последние 10 лет.

Напишите, вполне интерестно. Чет мне кажеться — проблемы две: 1)заказчик который не понимает как куа правильно пользоваться и 2) толпы куа джунов, которые ничего не знают и не умеют.

я би навіть виділив перший пункт. продуктивність дев + куа буде, як на мене, не менша ніж дев*2. А з/п в куа нижча =)

1)заказчик который не понимает как куа правильно пользоваться
Я бы сказал, что заказчик, который начал считать деньги и понял, что польза от больших QA команд не стоит затраченных денег

Analyse, Design, Testing — всегда были и остаются частью общего процесса. Сейчас циклы сокращаются, Agile, Scrum и т.п. Но тестирование как было необходимым, так и остается. Я соглашусь, что большое количество низкоквалифицированных работников — не нужно в тестирование, а где оно нужно?

Может умер QA каким вы его знали 25 лет назад?
Стращаете тут детишек...

А билды то кто тестить будет, в этом полном процессе? Разработчики? Или техподдержка?

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

Ну когда то они и програмировать не умели. Учить надо!. Таня, вы затронули столько болевых точек. На самом деле ведь вопрос изменения психологии. Просто то, что уже произошо на Западе теперь медленно докатывается до Украины.
«который отвечает за качество целого продукта» Если я вас правильно понял, то значит должен быть человек который отвечает за работу сделанную другими. А они за нее т.е. не отвечают?
«тот QA которым вы его видели лет 10-20 назад и умер» Тот QA который я видел 20 лет назад умер 19 лет назад, а тот что я видел 10 лет назад умер 9 лет назад. Все меняется. И то что мы видим сегодня умрет завтра.
Даже если принять «отдельный человек, который отвечает за качество целого продукта, а не отдельных кусочков, на проекте должен быть.» То понятно, что если когда то мы говорили про соотношение один к двум, то сегодня это один к команде, т.е. один к 8-12.

Если интересно может быть кто то создаст отдельную тему и мы можем подискутировать на тему QA и того куда оно идет.

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

И кто будет заниматься проверкой всего функционала который затрагивается той строчкой которую изменил разработчик? Кто будет проверять регрессию в разных областях? Кто будет писать и запускать автотесты? Наконец кто будет выяснять баг это или не баг, перед тем как что-то вообще делать?

Получается вместо пары dev+qa надо набирать dev+dev? Разработчики будут траться в два раза больше времени (Х дней на разработку и еще столько же на тестирование всего), а значит надо нанять в два раза больше этих разработчиков?

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

У меня два вопроса — вот это время на дополнительные изменения в планировании разработки (как писать код чтобы его автоматизировать) и в процессе разработки (сам процесс написания долнительного кода, не необходимого для самого приложения) — оно откуда возьмется?
Вместо dev+dev или dev+qa у вас получится 2*dev — столько же разработчиков, но в два раза больше времени на разработку.

И второй, с примером — допустим разработчик Вася собирался написать некую функцию с ошибкой, у него в условии стоит 1, а в спеке — 0. Вы предлагаете этому же Васе придумать как, а потом написать автоматическую проверку этого условия, где Вася так же напишет 1 (ну он же думает пока, что это правильно). Что делать в такой ситуации?

Андрей, я не думаю, что я смогу рассказать о всех деталях вот так. Предлогаю вам почитать немного о Test Driven Development, а так же о том как в реальной жизни на западе работает delivery in agile teams. Кстати, я абсолютно, не предпологаю, что вы уже этого не читали или не знаете. Просто там есть ответы на ваши вопросы.

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

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

Do you know what’s agile?
Yes.
Agile means shit.

На самом деле, ваш начальник прав отчасти. Сейчас в мире есть тенденция на уменьшение стоимости продукта и скорости его разработки в ущерб качеству. Это связано с увеличением кол-ва поставщиков-разработчиков на рынке.
Agile как раз увеличивает скорость разработки и уменьшает цену в ущерб качеству.

Никакого абстрактного «качества» вне сроков/стоимости не существует. Если решение нужно завтра, то послезавтра оно уже не будет качественным с точки зрения клиента, даже если будет идеальным архитектурно и технически.

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

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

кто будет пинать, если не будет QA?

Кволити к этим тестам отношения обычно не имеют. Это юнит тесты или интеграционые. Они не способны такое писать.

В девелопменте больше зп

1. Будь-який досвід в IT буде плюсом. Але, звісно, досвід 1 рік розробника значно краще ніж 1 рік тестування.
2. Якщо automation QA — то на відсотків 10-30% перекриєш знаня потрібні для девелопменту (і це лише BA, FE — взагалі доведеться самому вчити, адже для automation тестів його знань не треба). Якщо manual — тоді наврядче хоч щось потрібне для девелопера навчишся, окрім розуміння вимог і роботи з jira, TFS і тд.
3. Я би казав рухати в сторону програмування з Dev точки зору. Для тесутвання точно не зашкодить, а потім перейти буде в рази легше.
4. Зв’язані в тому плані, що і там і там потрібно писати код :) Але якщо у випадку з розробкою, то чуть не під кожну story інший підхід, інші паттерни, куча «свого» коду, то у випадку automation — спочатку розробка core, а потім, коли процес піднятий — монотоннний підбір тестових даних і написання тестових методів за шаблоном.

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

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

P.S. это мое личное мнение и да Java девы зажрались :)

Java devы разные бывают de.linkedin.com/jobs2/view/10689008 — как собственно и тестировщики -)

1. нормальные работодатели воспринимают положительно.
2. сможете, если захотите.
3. что Вам нужно знаете только Вы.
4. связаны, а на сколько сильно — зависит на чем именно автоматизировать.

1. Для джун девелопера опыт тестировщика — слабый козырь. Гораздо больший — достойные личные пет-проекты.
2. Нет. Эти профессии имеют очень мало общего (фактически, общего только то, что оба сидят за компом). Исключение — если ты пойдёшь аутомейшн-тесировщиком по той технологии, в которой в дальнейшем планируешь развиваться как разработчик.
3. Если хочешь быть тестировщиком — нужно.

по поводу п.2, ну да расскажите это в гугле и майкрософте -)

У мене в деякій мірі схожа ситуація із поправкою на те, що я вже 4-й рік в тестуванні.
Хочу перейти в автоматизоване тестування і в перспективі в розробку. Але в мене проблеми із менеджментом, котрий не дає апрув на мій перехід в команду, що займається розробою фреймворку для автоматизованого тестування нашого проекта. Постійно отримую відповідь аля «знайди для собі заміну і тоді, можливо, ми дамо апрув».
Вже починаю думати про зміну місця роботи. Але якщо переходити на іншу фірму, то чи шукати вакансії автоматизотора чи одразу junior developer (java)?

интересные вопросы, а что вам нравится то?

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

так двигайтесь именно в этом направлении, то, что вам нравится. Просто вопрос стоял или сразу java dev? Если нравится автоматизация тестирования, то двигайтесь в сторону автоматизации тестирования.

Я в свое тоже так выбрал QA, не советую) Если хотите получить опыт — идите сразу работать девелопером trainee «за еду». Можно даже совсем бесплатно. Многие большие компании дадут вам такую возможность, если напишите хорошее мотивационное письмо.

ИМХО с тестирование — єто все-таки IT-работа. И, если ты там не просто кнопочки будешь тыкать, то какой-то опыт будет идти, знакомство с технологиями теми же.. Вопрос тут такой: на какой работе ты сможешь больше времени уделять своему развитию.

Ситуация «И хочется и колется».

Вы вроде и хотите «ВайтиВАйТи», но хотите больше ДЕНЕГ (алчность фуфу, работа должна приносить кроме денег еще и удовольствие, если вы будете работать только потому что здесь БАБЛО, быстро перегорите и будете страдать).

1. Нормально, только сеньорити не сохранится скорей всего.
2. Мануальщиком врятли.
3. 50/50.
4. Только писанием скриптов на скриптовом языке, но не программированием в целом.

4. Только писанием скриптов на скриптовом языке, но не программированием в целом.
не совсем согласен с данным утверждением. Смотря что и как автоматизировать. Как ни странно в автоматизации крупных проектов чаще используется Java или С# , которые являются не совсем скриптовыми языками. Лично мне приходится еще использовать Spring и Hibernate. И все это в купе дало мне неплохой бэкграунд для перехода в разработку.

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

а что по вашему является программированием?

то чем не является ква автомейшн

автоматизацией является все -) вы же автоматизируете какие-то процессы или я ошибаюсь? -)

может я сейчас покажусь капитаном, но мы говорим о «ква автомейшн».

А на самом деле, да, мы все автоматизируем с помощью гугла и Ctrl+C / Ctrl + V.

не сразу понял что такое ква -)

Если вы все делаете исключительно Ctrl+C / Ctrl + V, то это ваши проблемы, а не автоматизаторов

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

Хм, в чем то похожие задачи, не правда?

Скорее всего вы даже не понимаете о чем говорите, а просто пытаетесь показаться круче за счет других.
Похоже так делаете именно вы ;)
А теперь напишите мне универсальный парсер таблиц который будет столбцы мапить на поля класса при этом для всех видов таблиц и полей.
Заимпортить ексельчик в приложушку распарсить и воткнуть куда надо? Это тоже работа для джунов ;)

З.Ы. И перестаньте вести себя как «в интернетах кто-то не прав!!!11111расрасрас», дискуссия уже давно зашла в тупик.

Похоже так делаете именно вы ;)
Вы работали автоматизатором?
Сразу отвечу на вопрос, да я работаю сейчас разработчиком.
Заимпортить ексельчик в приложушку распарсить и воткнуть куда надо
Распарсить рандомную таблицу на HTML странице
Вы работали автоматизатором?
Не обязательно быть автоматизатором ;)
Распарсить рандомную таблицу на HTML странице
Это задача для джуна...

З.Ы, Смотрите, а то скоро пригорать начнет...

Не обязательно быть автоматизатором ;)
Тогда не стоит писать о том, в чем вы не разбираетесь.
З.Ы, Смотрите, а то скоро пригорать начнет...
С такими клоунами дальше вести беседу бессмысленно. Смотрите как бы у вас потом не припекло.
Смотрите как бы у вас потом не припекло.
С такими суждениями шли бы вы к школьникам на форумы ;)
Тогда не стоит писать о том, в чем вы не разбираетесь.
Вот именно!)
С такими клоунами дальше вести беседу бессмысленно.
Я об этом еще давно написал. Пожалуй, продублирую:
З.Ы. И перестаньте вести себя как «в интернетах кто-то не прав!!!11111расрасрас», дискуссия уже давно зашла в тупик.
Смотрите как бы у вас потом не припекло.
С такими суждениями шли бы вы к школьникам на форумы ;)
Тогда не стоит писать о том, в чем вы не разбираетесь.
Вот именно!)
Знаете мир тесен и не стоит посылать всех подряд ;) Да и мания величия тоже не лучшие качество у разработчиков.
Знаете мир тесен и не стоит посылать всех подряд ;)
В школе застряли что-ли?
Да и мания величия тоже не лучшие качество у разработчиков
Да, ладно!

опять холливар, троллинг и деструктив...

А теперь напишите мне универсальный парсер таблиц который будет столбцы мапить на поля класса при этом для всех видов таблиц и полей.
от ЦЕ якраз те що відрізняє автоматизатора від девелопера...
останній знає що концепт називається ОРМ і просто заюзає одну з десятків ліб для цього...
+ архітектура коду корисна не лише йому (ака 100500 рядків в функції, один тест == одна функція), не «зараз працює — ну і добре»
от ЦЕ якраз те що відрізняє автоматизатора від девелопера...
останній знає що концепт називається ОРМ і просто заюзає одну з десятків ліб для цього
Только почему-то когда пришлось это делать для абсолютно разных HTML таблиц не нашлось универсальной и подходящей библиотеки. И вместо того что бы каждый раз писать похожий код, пришлось делать подобный механизм. И это куда сложнее чем в хибернейте прописать маппинг в xml

только ассемблер, только хардкор

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

Досвід в куа дасть вам бонус в дебагінгу і виявленні помилок, коли уже станете код писати. Ви будете трошки по-іншому дивиться на цей процес. + у вас буде можливість на цій же роботі перейти в розробники, якщо будете цього прагнути. Не слухайте, коли кажуть, що мануал це тупе клацання по кнопочках. Так само можна сказати і про розробників — ctrl+space за вас код пише. Ще і на чужих фреймворках.

Стосовно деяких ваших запитань:
1. Досвід куа переб’є негативну реакцію на академію ШАГ.
2. Зможете. Робота із системами контроля версій, дебагінг, пошук причин проблем, спілкування із замовниками або іншими колегами.
3. Вся теорія по тестуванню надумана, щоб купляли курси і сертифікати. Десь тут на доу був пост про 100500 видів тестування. Можете прочитати і забути одразу. Весь вільний час присвятіть розробці чогось, що стане в пригоді на роботі. Наприклад: напишіть пару тестів, автоматизуйте процес деплоя, зробіть морду для показу статистики на проекті або ще чогось. Підніміть у себе продукт, яким займаєтесь. При тестуванні самі шукайте де проблема в коді, репродюсьте, репорьте із вашими доказами. Це полегшить роботу розробнику. Через пів року уже можете мутить воду, щоб перевели в розробники — досвід із продуктом є, знаєте де що і тд. Просто підійдете і скажете, що хочете перейти і спитаєте, що для цього треба. Це буде легше, ніж іти в іншу контору одразу девом.

Робота із системами контроля версій, дебагінг, пошук причин проблем,
це ви точно про тестерів?

В чем причина сомнений? Чем же по вашему занимаются тестировщики?

описують що треба зробити щоб щось пішло не так, і власне перед тим знаходять що візуально «не так».
крім випадку тестування АПІшки/потокового перетворення даних, спроба «вгадувати» де і через яку ревізію «все поламалось» це зазвичай втрата і так обмеженого часу та висновки що автоматом підуть в смітник (на основі досвіду ЮІ вгадувати яка реалізація в коді зазвичай нідочого доброго не приводить)

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

Речь шла о тестировщике, который желает стать разработчиком
ні, йшлося про людину що не сильно робить свою роботу, і трохи більше заважає іншим...
так же ничего не мешает вам этим заниматься после формального оформления бага.
я ще не бачив жодного гарного КУА в кого було хоч трохи вільного часу.... вийнятки — “в нас ще вимог нема — хз що робити”

ну я цим всім займався будучи мануал куа. Головне не отримати помилку в програмі, а знайти що її спровокувало, в яких умовах і, ідеально, найвужче місце в коді, де воно падає. Якщо помилки не було в минулому білді, а тепер є — то в контролі версій можна переглянути, що мінялося, ким і коли. Це зменшує час пошуку помилки в рази. Заодно можна побачити і інші шляхи до цієї помилки. Ну і подебажить можна ще :-)
На клікерів, які тестять веб аплікухи по 2 роки і не знають про Dev Tools, дивлюся дивно дуже.

ідеально, найвужче місце в коді, де воно падає.
от до цього — все правильно, а тут ви витрачаєте нееффективно свій час на те що у вас буде погано виходити, через обєктивно гв рази гірше розуміння внітрішньої роботи аплікухи, і відповідно погіршуєте показники своєї основної роботи — перевірка якості софту в обмежений час.
На клікерів, які тестять веб аплікухи по 2 роки і не знають про Dev Tools, дивлюся дивно дуже.
менеджери, які знають що ви на позиції тестера більшість часу самовільно проводити в дев тулзах — мали б до вас щодня приходити з клізмою, і розказувати що те що ви робити девелопер зробить за х/3 часу і не буде мати простоїв через занадто довге тестування.
вийнятки — специфічні проекти, особливо з публічною АПІ, але це таки вийнятки

на практиці у мене було навпаки: я витрачав в два рази менше часу, ніж девелопер, щоб знайти рут коз.

у вашому випадку виходило, що тестер каже девелоперу «кнопочка не работает», а девелопер казав " а у меня работает". і починався пінг понг вияснення що ж там упало. хоча в дебазі все одразу ясно на куа енвайроменті

я витрачав в два рази менше часу, ніж девелопер, щоб знайти рут коз.
якщо у вас були такі девелопери — то ви просто були не на свому місці/не тому проекті.
в загальному випадку лізти в код будучи КУА — це витрачати свій і так цінний час на те що ви еффективно не зможете розібратись, і робити висновки які скорше за все будуть відкинуті.
у вашому випадку виходило
варіанти аж два:
а) описати якісно що для того треба зробити, щоб відтворити
б) прийти, і наклікати на компі девелопера, паузу в підключеному дебагері він певно вже сам здогадається натиснути.
перший степ обовязковий, для майбутніх поколінь, другий — опціональний, залежить від відносин в тімі.
хоча в дебазі все одразу ясно
false.
в дебазі ясно де виліз ексепшин/в яку функцію прийшов налл параметром, але це не є «root cause», це лише симптом, а лікувати треба оригінальну проблему, яку без знання внутрішньої архітектури ви просто не будете бачити.

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

Если уж у вас есть цель, я бы не тратил время на действия, которые к этой цели не приближают. Тем более, что «какая-нибудь работа в принципе» у вас и так есть.

1. Как воспримут потенциальные работодатели опыт тестировщика, в случае начала карьеры разработчика ПО в будущем?
хорошо воспримут, если качество продукта важно для них, что далеко не всегда — факт)
2. Смогу ли я получить в процессе работы тестировщиком, знания и навыки, которые мне пригодятся в разработке ПО?
мануальное тестирование может привить правильный подход — от качества, а вот автоматическое тестирование это уже путь к качественному кодингу
3. Нужно ли мне тратить время на глубокое освоение области тестирования или направить все усилия на изучение программирования?
Область тестирования не такая и большая если уловить суть, а усилия на изучение программирования — прямой путь в девелопмент, вполне возможно зрелый, качественный девелопмент, а это большая редкость
4. На сколько сильно связанны — автоматизация тестирования и программирование(и в чем)?
напрямую — и там и там разрабатывают, SEIT — тот же девелопер на высоком уровне со специализацией в тестировании
Как воспримут потенциальные работодатели опыт тестировщика, в случае начала карьеры разработчика ПО в будущем?
ну вот как переход с не айти в тестеры, такой же переход будет с тестеров в программисты, все с самого нуля, а еще если задержишься и, допустим, будешь зарабатывать 1.5к тестером, то уходить на трейни разработчика с зп 0,3к как-то не очень
Смогу ли я получить в процессе работы тестировщиком, знания и навыки, которые мне пригодятся в разработке ПО?
нет, в процессе работы мануальным тестером ты никаких знаний вообще не получишь, разве что как работает тестируемый софт, а будешь ли ты учить параллельно программирование уже от тебя зависит
Нужно ли мне тратить время на глубокое освоение области тестирования или направить все усилия на изучение программирования?
да нечего особо учить в области тестирования, разве что теорию, которая не пригодится, посмотри резюме синьор разработчиков и синьор тестеров, разница поразительная, у одного список технологий, у другого хобби и сильные стороны
На сколько сильно связанны — автоматизация тестирования и программирование(и в чем)?
почти никак

Ответ сильного, независимого разработчика

Как воспримут потенциальные работодатели опыт тестировщика, в случае начала карьеры разработчика ПО в будущем?
Положительно, хуже чем опыт разрабом, но лучше чем опыт менеджером по продажам. Гораздо лучше полгодика поработать тестером, чем сидеть на пятой точке ровно и что-то, возможно, учить. Зависит от того, насколько в тебе сильна самодисциплина
Смогу ли я получить в процессе работы тестировщиком, знания и навыки, которые мне пригодятся в разработке ПО?
Получишь общие знания, плюс полезно взглянуть на процесс с другой стороны баррикад.
Нужно ли мне тратить время на глубокое освоение области тестирования или направить все усилия на изучение программирования?
Глупый вопрос, выбирай, что тебе интереснее и вперед.
На сколько сильно связанны — автоматизация тестирования и программирование(и в чем)?
Вполне себе связаны, на любом более менее приличном проекте имеется тестовый фреймворк, наследование, ввод данных, вывод данных — все это есть в автоматизации.
Положительно, хуже чем опыт разрабом, но лучше чем опыт менеджером по продажам
подход «лучше что-то чем ничего» плохо работает, вообще не представляю пользы от этой положительности.... больше денег — нет, больше шансов на найм — нет, работал в айти до этого молодец — а теперь на сабы на общих условиях, программист, который делает бесцельные вещи — говнокодер, это не в почете
Получишь общие знания, плюс полезно взглянуть на процесс с другой стороны баррикад
нафига? еще скажи кругозор расширить, так почему бы не поработать курьером, еще больше кругозор расширится
Глупый вопрос, выбирай, что тебе интереснее и вперед.
+1
Вполне себе связаны, на любом более менее приличном проекте имеется тестовый фреймворк, наследование, ввод данных, вывод данных — все это есть в автоматизации.
только тестер автоматизатор хуже джуна разработчика пишет обычно, абсолютно забив на обязательные вещи и никогда не брезгует лютым копипастом и говнокодом, бывают исключения, но либо совсем много такому платят, либо он уходит в разработчики
только тестер автоматизатор хуже джуна разработчика пишет обычно, абсолютно забив на обязательные вещи и никогда не брезгует лютым копипастом и говнокодом
Таких надо гнать в шею. Автоматизация это та же разработка, только приложения которое тестирует другое приложение.
нафига? еще скажи кругозор расширить, так почему бы не поработать курьером, еще больше кругозор расширится
Не вижу ничего зазорного в опыте работы курьером, как минимум научишься общаться с людьми
подход «лучше что-то чем ничего» плохо работает, вообще не представляю пользы от этой положительности.... больше денег — нет,
Хватит про деньги
работал в айти до этого молодец — а теперь на сабы на общих условиях, программист, который делает бесцельные вещи — говнокодер, это не в почете
Именно бесцельными вещами и будет заниматься разработчик после ШаГа, сидя дома и кушая мамкин борщ. А на другой чаше весов реальная вакансия, прямо здесь и прямо сейчас. Еще и в другом городе, отличный способ выйти из зоны комфорта.
только тестер автоматизатор хуже джуна разработчика пишет обычно, абсолютно забив на обязательные вещи и никогда не брезгует лютым копипастом и говнокодом, бывают исключения, но либо совсем много такому платят, либо он уходит в разработчики
Вас обидел в детстве автоматизатор? Не стоит ровнять всех под одну гребенку.

о Господи, все SDET в майкрософте гавнокодеры -) как же так... ты перевернул мой мир

Дык все по своим бодишопам судят :)

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

Вы за всю страну говорите? Кто Вы собственно такой ? -)

Всё в порядке, Вадим со мной.
А вот за мной уже вся Украина!

главное чтобы людей в белых халатах не было за тобой -)

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

выгодней в плане чего? денег? -)

ну а чего же еще? любой бизнес ориентирован на деньги, ну кроме убыточного :) большинство людей ориентированно на увеличение дохода, айти не исключение s.dou.ua/...s/portrait2015infogr5.png

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

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

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

Я вот тоже в положении, похожем на положение автора. Только работу QA,мне никто не предлогал. Но как-то я обдумывал такой вариант, а что если. В общем я бы не согласился, даже на + зп, даже на automation. Не мое.

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

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

О, вот это хороший вопрос! Сам прохожу через это и вот тебе мой совет: НИ В КОЕМ СЛУЧАЕ НЕ ИДИ МАНУАЛКУ, ОТ МАНУАЛЬНОГО ТЕСТИРОВАНИЯ УМИРАЕТ ДУША!!! Я вполне серьезно. Представь — ты человек с техническим складом ума, любишь программирование, обожаешь технологии, но 40 часов в неделю вынужден кликать (зачастую бездумно) по кнопочкам и писать всякие бумажки типа чеклистов, что никакого развития тебе как программисту не дает и дать не может, одна деградация. Теперь конкретно по твоим вопросам:

1. Как воспримут потенциальные работодатели опыт тестировщика, в случае начала карьеры разработчика ПО в будущем?
Да в общем никак, это совсем небольшой +, который выражается в том, что у тебя будет опыт работы в команде и тому подобные вещи.
2. Смогу ли я получить в процессе работы тестировщиком, знания и навыки, которые мне пригодятся в разработке ПО?
Практически нереально в работе мануалщиком получить знания и навыки, которые пригодятся в разработке. Разве что будешь по старой памяти перед коммитом прогонять пару happypath-тестов и научишься проще относиться к багам, которые будут на тебя заводить.
3. Нужно ли мне тратить время на глубокое освоение области тестирования или направить все усилия на изучение программирования?
ТОЛЬКО ПРОГРАММИРОВАНИЕ, ТОЛЬКО ХАРДКОР! Поверь, ты только зря время потеряешь. Потрать полгода, подтяни знания, разучи пару ходовых фреймворков и иди сразу на программиста, не разменивайся на мелочи.
4. На сколько сильно связанны — автоматизация тестирования и программирование(и в чем)?
Автоматизация тестирования связана с программированием тем, что нужно программировать, но специфика другая и конечный продукт в корне отличается. В автоматизации есть крутой момент, что ты за полгода-год можешь перепробовать кучу языков и технологий, правда всё это на весьма поверхностном уровне.

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

Дехто йде шляхом «мануальний тестувальник — автоматизатор — девелопер». Тільки це вимагає відповідних умов в компанії/компаніях та чимало ваш сил і ресурсу для самонавчання. Знаю приклади зворотнього шляху — він легший.

1) Чесно, залежить від людей які вас найматимуть. Комусь по-шарабану, хтось буде бачити у вас кар’єриста (ага, захотів більше грошей), а хтось вважатиме що мислення тестувальника та розробника знаходяться у протилежних кутках кімнати, тому їм не по дорозі.
2) Все залежить від вас. Якщо навчатиметесь — тоді само собою. Так чи інакше, тестування, QC — це частина життєвого циклу розробки продукту. Якщо ж просто будете тупити і косити під середнячка, лиш би відсидіти попо-години, — тоді ефекту буде менше.
3) Якщо виберете шлях «тестер — автоматизатор — девелопер» — так. Якщо поставите за ціль перейти з тестування в розробку у вашій конкретній компанії — так (потрібно ж показати, що ви відповідальний і досягаєте успіху в речах, за які беретеся). Якщо збираєтеся через 1-1,5 роки просто піти шукати роботу розробника — скоріше ні, чим так.
4) Залежить від проектів. Інколи — абсолютно нічим не зв’язані. Написання простих скріптів і нормальна розробка — різні напрямки. Але є випадки (напр, Software Engineer in Test) — коли грані дуже тонкі або й відсутні. Все таки цілі між напрямками різні, як і інструмент. Ну і в більшості випадків в Україні (до 90%), єдине що спільне — це синтаксис тієї чи іншої мови.

Зважаючи на ситуацію на ринку, я б заходив через мануальне, з ціллю максимум через 2 роки перейти в розробку. До того часу, можливо вдастся дотягнутися до мідл рівня тестувальника та прокачати свої скіли у розробці. Але вирішувати вам, поки студент — втрачати особливо нема чого, тоді чому б не спробувати?

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

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