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

Не тянешь на программиста — иди в QA?

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

В Фейсбуке встретил рекламу с завлекаловом:

Профессия QA идеально подходит для тех, кто хочет работать в IT, но не видит себя программистом

И случился у меня баттхерт. Здесь и далее я буду регулярно путать QA и QC, за что сразу ж посыпаю голову пеплом. Говорю о крупных-аутсорсерах, потому что в конторах помельче зачастую просто не выделяют отдельную позицию, ну, а где выделяют — требования всё ж помягче.

А еще — речь скорее о Manual QC. Написание интеграционных автотестов — там уже проще, но такой зверь всё еще редкий.
Так вот. О мифе. Мифе про «низкий порог входа».

1. От джуна QC ждут, что он достаточно хорошо знает английский. Если он не в состоянии зарепортить багу, чтоб её можно было воспроизвести — он просто тратит время команды впустую. От девелопера такого не ждут. Если толковый, но даже письмо написать не сможет — окей, возьмут под «честное слово» обучиться, и попервой за него будет говорить кто-то из команды.

2. От джуна QC ждут и других софт-скиллов. Например, коммуникативности(пояснить), настойчивости(девелопер убеждает, что это «не наше дело» и «давай, не будем больше никого трогать и просто закроем багу»). И это не полный список, да.

3. Джуну QC сложно продемонстрировать навыки. «Тестирование карандаша» — неизбежное зло, где-то на уровне «а теперь напишите на бумаге работу с красно-черным деревом» для разработчика. Если разработчик может сделать тестовое задание или предъявить репо на github, джун QC на собеседовании может только рассказать, какой он обучаемый.
Да, когда есть ICTQB-сертификат становится легче, но я говорю о старте и джунах.

4. Если накосячит джун-разработчик — его страхует тима: даже если формального код-ревью не происходит — код все равно читается остальными. И еще его тестируют автотесты и тот же отдел QC.
Если накосячит джун-QC(невнимательно пройдется по шагам баги и закроет все еще актуальное), может быть все что угодно(точнее, только одно — упущенные проблемы). А дублировать всё-всё, сделанное джуном QC — попросту не рационально.

5. Девелопер-новичок может всё же приносить измеримую пользу проекту, если ему ставить небольшие, изолированные, легко проверяемые задачи. Потому что проверить все же быстрее, чем реализовать.
Для QC как может выглядеть проверка? Пройтись за джуном по всем пунктам — это просто затратить столько же времени. Рационально? Думаю, нет.

tl; dr; От новичка QC ожидают большего, чем от новичка-разработчика. Причем требования плохо формализованы и сложнопроверяемы. Так что по окончанию курсов QC сложнее «войти в айти».

Посмотрите на статистику вакансий на ДОУ. QC-вакансий меньше, чем сугубо PHP-шных. Потому что взять 3 джунов девелоперов и одного синьора над ними — имеет смысл(хотя, как бизнес-план так себе). А 3 джунов QA и одного тестлида — уже тянет на диагноз.

PS Пожалуйста, не «идите в QC» только потому, что вам рассказали, какой там низкий порог входа. Реальность настигнет очень быстро. И больно.

[UPD] загляните в тему со смежной точкой зрения: Свитчерам в IT

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

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

Не тянешь в QA — иди в PMы

Хотел было написать на практически каждое предложение, написанное автором, почему многое, так скажем, не совсем верно... А потом подумал что в интернете все равно кто-то всегда не прав, но, тем не менее, все имеют право на мнение. Пусть так и будет :)

Ограничусь парой ремарок:
— Порог входа ниже, чем в «любого» программиста. Он даже ниже чем в любой язык программирования как в таковой. Нравится вам это или нет — это факт.
— 95% вакансии на Junior QA не постят, подумайте почему.
— Junior QA, QA Trainee/Intern и QA после курсов (и смотря после каких) — очень разные QA-и.
— Количество «желающих» не создает большой конкуренции, так как 90-95% от всех желающих — на 3 головы ниже чем те 5% из общей массы, что получают работу, так как действительно обладают нужными знаниями и умениями. Проблема компаний — найти эти 5% в «массе», проблема новичков — не умение правильно «помочь» компаниям их найти (начиная с грамотно составленного/отправленного CV, заканчивая ленью).
— Фраза «не тянешь на программиста — иди в QA» имеет такой же смысл как и фразы «не тянешь Java? — иди в PHP» «не тянешь на слесаря? — иди водопроводчиком» «не тянешь на механика СТО? — иди водителем» — надеюсь, моя метафора ясна.

P.S.:
Все кто идут в 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

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

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

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

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

статью не дочитал, но что такое QC?

все что вы думаете , что это QA работа- чаще QC на самом деле.

Борьба за качество — это право тех, кто хочет это делать. Разбираться в этом после прохождения курсов легче. Самое главное, чтобы человек точно знал, что он хочет. В идеале, тестировщик ПО, QA, QC должен любить или хотеть любить следующее: *Английский, *Математику, *Веб-дизайн (просто любить его за его существование), *Экономику, *Работу в разных ОС, *Приносить пользу всему IT сообществу, *Объяснять суть проблемы, *Общаться с разработчиками и заказчиками, *Вычитывать контент, *Искать легкие пути, *Упрощать, *Систематизировать, *etc.

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

Спорьте. А то так непонятно даже что именно рьяно не так)

Ок.
Далеко не все ПО нынче хоть как-то связано с вебом. Равно как и не все ПО требует кросс-платформенности. Отсюда вывод: далеко не всем нужна любовь к веб-дизайну и разным операционкам.
С экономикой вопрос еще интереснее. Я ее применение вижу в 2 случаях:
— ПО, как-то связанное с ней;
— Посчитать трудозатраты на релиз / проект, ROI для автоматизации или еще что-нибудь из этого.
Собственно, в первом пункте любовь к экономике, наверное, не помешает — но, опять же, с этой доменной областью далеко не все проекты.
А со вторым... Если подсчет подобных штуковин занимает большую часть времени, то это уже как бы не QC/QA. А если это надо сделать раз в пятилетку — то и без любви это можно пережить (впрочем, даже раз в пятилетку такими подсчетами не каждому тестировщику приходится заниматься).
Потому все-таки зачем любому хорошему QA/QC любить вышеперечисленное?
И раз уж у нас завязывается беседа, расскажите подробнее, пожалуйста, про «приносить пользу всему ИТ-сообществу»: это что и как? И если можно, с именами-примерами.

Итак.
«1. Далеко не все ПО нынче хоть как-то связано с вебом. Равно как и не все ПО требует кросс-платформенности. Отсюда вывод: далеко не всем нужна любовь к веб-дизайну и разным операционкам.
2.
С экономикой вопрос еще интереснее. Я ее применение вижу в 2 случаях:
— ПО, как-то связанное с ней;
— Посчитать трудозатраты на релиз / проект, ROI для автоматизации или еще что-нибудь из этого.
Собственно, в первом пункте любовь к экономике, наверное, не помешает — но, опять же, с этой доменной областью далеко не все проекты.

А со вторым... Если подсчет подобных штуковин занимает большую часть времени, то это уже как бы не QC/QA. А если это надо сделать раз в пятилетку — то и без любви это можно пережить (впрочем, даже раз в пятилетку такими подсчетами не каждому тестировщику приходится заниматься).
Потому все-таки зачем любому хорошему QA/QC любить вышеперечисленное?

3.И раз уж у нас завязывается беседа, расскажите подробнее, пожалуйста, про „приносить пользу всему ИТ-сообществу“: это что и как? И если можно, с именами-примерами.»
_______________________________________________
Итак, Татьяна, смотрите что я думаю.
Во-первых, во-вторых и в третьих, любовь к операционкам нужна тем, кто в них работает, веб не предпочитают те , кто с удовольствием работает в Линукс и\или администрирует СУБД, возможно. А подсчитать кое-что из затрат учат даже в школе, на уроке Экономике, там же внушают любовь ко всем наукам и знаниям.Если кто-то думает иначе , чем я, то это еще не значит, что я не права. Экономика предприятия присутствует почти во всем, что связано с работой в офисе. Синонимы предприятия: офис, компания, фирма. И получается, если исходить из темы «„Не тянешь на программиста — иди в QA?“», то тому, кто реально долго учился именно на программиста и почему-то теперь не получается... Можно пойти в тестеры или в QA, а можно закончить курсы программистов, поучить другой язык, не тот который был в Дипломном проекте или изучался на 3-4 курсе Универа. Попробовать тот же Веб. Все, кто программиста видит как чисто кодера и конечо же, только компьютерного гения, который знает C,C#, Java, Вносит изменения в Бейсик 7.0 и писать в консоле его мечта, на всякий случай, а также паять, и придумывать перед этим микросхему, так вот , те кто думает таким образом,я думаю заблуждаются. Веб — это... обратимся к той же Википедии
«Веб-программирование -
раздел программирования, ориентированный на разработку веб-приложений (программ, обеспечивающих функционирование динамических сайтов Всемирной паутины).
Языки веб-программирования — это языки, которые в основном предназначены для работы с веб-технологиями. Языки веб-программирования можно условно разделить на две пересекающиеся группы: клиентские и серверные.
«Серверные языки
Когда пользователь дает запрос на какую-либо страницу (переходит на неё по ссылке или вводит адрес в адресной строке своего браузера), то вызванная страница сначала обрабатывается на сервере, то есть выполняются все программы, связанные со страницей, и только потом возвращается к посетителю по сети в виде файла. Этот файл может иметь расширения: HTML, PHP, ASP, ASPX, Perl, SSI, XML, DHTML, XHTML.
Работа программ уже полностью зависима от сервера, на котором расположен сайт, и от того, какая версия того или иного языка поддерживается. К серверным языкам программирования можно отнести: PHP, Perl, Python, Ruby, любой .NET язык программирования (технология ASP.NET), Java, Groovy.
Важной стороной работы серверных языков является возможность организации непосредственного взаимодействия с системой управления базами данных (или СУБД) — сервером базы данных, в которой упорядоченно хранится информация, которая может быть вызвана в любой момент.
Фреймворки
См. Веб-фреймворк.»
Это нам пишут на Вики... исправляют кстати. И тут тоже мнения разошлись.
Исходя из того что, СУБД на Линуксе или другой Юникс будет потом раздавать данные пользователям офисов. А там в основном у всех Винда, то знания веб все-таки пригодится и удачливому и не очень везучему программисту, даже чтобы просто с телефона зайти в браузер и конечно же не гуглить, ведь это любимый браузер всех, а любить почему-то чуть-ли не запрещено. Зайти в поисковик написанный им самим) и «погуглить» не любя.. а та-а-а-к... надо и все. Поэтому, я не отношусь к тем, кто не хочет знать экономику и любить ее. Это ведь мое мнение.
Так вот, получается, что Программист, который так и не собрался ни на QA, ни на QC, ни на мануального тестера, может спокойно кодить все что хочет! И даже не знать почти английского языка, тем более экономику.
А вот тестировщику, который на всю жизнь решил связаться с тестированием, лучше полюбить всё и сразу. Мало ли что придется тестить.
Тем, кто знания приуменьшает, конечно же не надо ничего любить. Можно просто знать.Можно перефразировать: хорошо относиться, иметь среднюю степень знаний, получить вводный курс по этим наукам, прочитать самому при надобности. Просто, чтобы не удивлялись потом. сли на собеседовании спросят:"А как вы относитесь к экономике?«)

«И раз уж у нас завязывается беседа, расскажите подробнее, пожалуйста, про „приносить пользу всему ИТ-сообществу“: это что и как? И если можно, с именами-примерами.»
Татьяна, привожу примеры.Все тестировщики ПО, добросовестно выполняющие свою работу. Картинки повсюду.
Я не могу найти обратных примеров. Примеры тестировщика, даже специалиста по качеству, которые не приносят пользу?? Конечно же, сама работа заключается в этом. Просто, чтобы знали. А то будут думать, что просто сидят и пишут и тестят. Нет! QA создано для того, чтобы приносить пользу всем. Качественным ПО все хотят пользоваться. Все просто.


Татьяна, привожу примеры.Все тестировщики ПО, добросовестно выполняющие свою работу. Картинки повсюду.
Я не могу найти обратных примеров. Примеры тестировщика, даже специалиста по качеству, которые не приносят пользу?? Конечно же, сама работа заключается в этом. Просто, чтобы знали. А то будут думать, что просто сидят и пишут и тестят. Нет! QA создано для того, чтобы приносить пользу всем. Качественным ПО все хотят пользоваться. Все просто.Татьяна, привожу примеры.Все тестировщики ПО, добросовестно выполняющие свою работу. Картинки повсюду.
Я не могу найти обратных примеров. Примеры тестировщика, даже специалиста по качеству, которые не приносят пользу?? Конечно же, сама работа заключается в этом. Просто, чтобы знали. А то будут думать, что просто сидят и пишут и тестят. Нет! QA создано для того, чтобы приносить пользу всем. Качественным ПО все хотят пользоваться. Все просто.
Нет, ну так не интересно :) Изначально у вас была достаточно высокопарная фраза про пользу для всей ИТ-отрасли. Лично для меня это подразумевает, ну, не знаю... Придумать новый подход к тестированию (к примеру) тех же сайтов, который смогут успешно применить хотя б процентов 15-30 веб-проектов. Или создать /вдохновить на создание какого-нибудь полезного тула, который опять же, можно будет применить не в одном проекте. Но таких людей единицы. А хороших тестировщиков все же побольше.
А если речь идет только о «добросовестно выполнять свою работу», то это, имхо, стоит и называть соответсвенно. Если добросовестность звучит слишком просто, то можно назвать это пользой для проекта, для заказчика, для конечных пользователей. И при такой формулировке по этому пункту я даже искренне с вами соглашусь.
P.S. По остальным пунктам я отпишусь в следующем комментарии, дабы не создавать «простыни».

Итак, Татьяна, смотрите что я думаю.
Во-первых, во-вторых и в третьих, любовь к операционкам нужна тем, кто в них работает, веб не предпочитают те , кто с удовольствием работает в Линукс и\или администрирует СУБД, возможно.
Наталья, надеюсь, я вас не очень удивлю, если скажу, что даже под Винду существует не только веб? Не говоря уже про «злобный бекенд» под Unix (у которого, кстати, в рамках проекта может вообще не быть графического интерфейса). Или приложения для мобильных телефонов.
И это все тоже тестируют живые люди :) и даже если они не любят (и даже не знают глубоко!) веб — это не сделает их не хорошими тестировщиками.
И если человек любит веб, а его посадить за все эти «игрушки» — ну, вряд ли человек будет счастлив (и это даже может сказаться на его хорошести как тестировщика в худшую сторону — для данного конкретного проекта).
И сюда же если я люблю только Винду, а все остальное не люблю — не хочу — не буду — то это личное право каждого, и никто никого не заставляет идти на те проекты, где есть что-то кроме Винды.

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

Экономика предприятия присутствует почти во всем, что связано с работой в офисе. Синонимы предприятия: офис, компания, фирма.
И что?

И получается, если исходить из темы «„Не тянешь на программиста — иди в QA?“», то тому, кто реально долго учился именно на программиста и почему-то теперь не получается...
Извините, тут мы отвлекаемся от темы «что нужно хорошему тестировщику», потому некоторую часть я из цитат я опущу.

Это нам пишут на Вики... исправляют кстати. И тут тоже мнения разошлись.
Исходя из того что, СУБД на Линуксе или другой Юникс будет потом раздавать данные пользователям офисов. А там в основном у всех Винда, то знания веб все-таки пригодится и удачливому и не очень везучему программисту, даже чтобы просто с телефона зайти в браузер и конечно же не гуглить, ведь это любимый браузер всех, а любить почему-то чуть-ли не запрещено. Зайти в поисковик написанный им самим) и «погуглить» не любя.. а та-а-а-к... надо и все.
Я повторюсь: даже в Винде не вебом единым. И зачем каждому (тем более тестировщику) свой самописный браузер и свой самописный гугл? Что-то я совсем запуталась.
И да, неужели правда не чувствуется разница между утверждениями «любить веб не обязательно» и «любить веб запрещено»? :))

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

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

Тем, кто знания приуменьшает, конечно же не надо ничего любить. Можно просто знать.Можно перефразировать: хорошо относиться, иметь среднюю степень знаний, получить вводный курс по этим наукам, прочитать самому при надобности.
Значение знаний я не преуменьшаю (если преуменьшение знаний — это об этом). Я всего лишь пытаюсь показать, что хороший QA/QC в РАЗНЫХ областях должен обладать РАЗНЫМИ знаниями и умениями.
Впрочем, «любовь к» и «знания в» далеко не идентичны.

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

Профиль — очень даже отличный! Мне нравится! И в отличии от многих, я ничего не придумываю. А спокойненько учусь на обычных курсах, которые регулярно проводит Компания, конкретная, упомянутая в профиле. Спасибо за комментарии! Вы меня развеселили)

На счет профиля повеселили меня вы — я о нем не говорила ни слова :)

Экономику
А це до чого?
Судячи з Вашого посту, ці всі курси все більше нагадують деструктивні секти якісь.
Профіль LinkedIn дуже дивний

Профиль — очень даже отличный! Мне нравится! И в отличии от многих, я ничего не придумываю. А спокойненько учусь на обычных курсах, которые регулярно проводит Компания, конкретная, упомянутая в профиле. Спасибо за комментарии! Вы меня развеселили)

, *Вычитывать контент,
а это нам зачем??? А контент-менеджеры чем будут заниматься?

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

Выходит по вашим словам у тестировщика должно быть ещё филологическое образование??? Для того что бы как вы сказали "

А тестировщик отвечает и за грамотность.
"

Предполагается, что грамотно писать человека учат еще в школе. А не на филологических факультетах, вопреки распространенному заблуждению :)

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

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

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

Не тянешь на продавца МакДональдз — иди в программисты

Чуть больше года назад я решил стать тестировщиком. Прочитал аж целого Савина и половину Канера и рванул в одну известную харьковскую компанию на курсы. Так вот, я даже прошел тестирование, лол. Завалился на собеседовании, так как в тот момент ничего не понимал о программировании, ничего от слова «вообще», а курсы все-таки были на автоматизаторов, а не на мануальщиков, так что меня справедливо завернули со словами «ты нам понравился, мы тебе кинем список литературы, читай и приходи на следующий набор».
Я начал учить джаву, а QA мне в процессе быть расхотелось, но это уже другая история.
Я к чему это все: порог вхождения в QA реально ниже, если бы я на момент собеседования мог ответить на элементарнейшие вопросы уровня «опиши на словах сортировку пузырьком» и «расскажи об ООП и его принципах», меня бы взяли и, возможно, я бы уже трудился как junior QA. Такие дела.

В Харьков -да, в Киеве — посложнее..
И опять же вы не факт, что после курсов вас бы взяли на работу..

Безусловно. Но это уже весьма неплохая база для поиска работы в любом случае.

тут речь идет о том, что даже с хорошей базой очень тяжело найти работу в QA(QC) для джуна..

А нафига для QA знание сортировки пузирьком? Лучше знание английского и что такое тест кейс.

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

Ну я понимаю спросили бы про классы, объекты, ООП, циклы, но зачем знать про сортировку пузырьком ?

Даа мне какраз дали задание писать такой велосипед) Всегда был мануальным тестировщиком а теперь нужно написать свой ДДТ фреймворк :)

Та ну хрен их знает. Алгоритмическая подготовка?
В любом случае, это у них надо спрашивать :)

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

Юнит тесты пишут программисты, а вот как раз что бы написать грамотный фреймворк ( на основе page object) очень нужно знание ООП.

О госпади... создать 2-4 базовых класса и унаследоваться от них — это «очень нужно»?

А ещё знать зачем нужны абстрактные классы и интерфейсы. Вот уже и нужнее чем сортировка пузырьком

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

Какой это кодер будет тестировщику писать Фреймворк? Нахрена тогда автоматизаторы если кодер может и сам пользоваться своим фремворком и кодить тесты

Подозреваю что юнит тесты и авто тесты немнога разные вещи.

Подозреваю человек не знает какие фреймворки пишут тестировщики.

подозреваю человек не знает что такое фреймворк.

Знаю точно ибо приходится его писать. На Maven+JUnit+Selenium используя Data Driven подход

видимо для автоматизаторов.

Если бы знали лучше теорию — прошли бы куда? На курсы?
<sarcasm>Вижу вы много знаете о трудоустройстве и пороге входа :)</sarcasm>

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

В моей молодости эта фраза звучала

Не тянешь на программиста — иди копай траншеи в 30 градусный мороз

Где вы видели в Украине 30 градусный мороз?)

20 лет тому назад, причем −20 градусов эта была норма, чтоб гулять.

да, прошли те времена...

В луганске каждый гол неделю или две был

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

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

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

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

Я с вами не согласен что бесполезные. Какраз вопросы могут показать наличие алгоритмического мышления, или в случае с карандашем — out of the box thinking.

Другое дело что собеседующие могут неправильно к этому подходить.

ну, потенциально — да. но в отличие от тестового задания «на вынос», это-то выполняется в условиях ограниченного времени, стрессовом состоянии(начиная с непривычной обстановки и заканчивая «экзаменатором», который сидит и смотрит на тебя в упор) и невозможность использовать внешние источники информации.
в итоге, не сделал задание — не говорит об отсутствии знаний.
сделал — не говорит о широкой эрудиции. человек мог просто пару алгоритмов просто зазубрить.
вишенькой на тортик — кейс, когда после задачи на то самое красно-черное дерево человека берут формы на angular’e клепать.

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

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

для интервью тренируюсь

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

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

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

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

Ну как сказать, не нужны. Парочка сортировок и 2-3 структуры вспомнить точно придется.

И по поводу реализации. Ее не нужно помнить от слова вообще. Если знаешь алгоритм, то закодить уж как нибудь можно

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

Если честно, я ничего не поняла

4 первых момента — это и есть задача? может ее иначе сформулировать можно? в каком вузе учат?

поняла, даже не слышала никогда про

ТВиМС

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

накатать красно черное дерево — это краснодеревщик, точно не QA

От новичка QC ожидают большего, чем от новичка-разработчика. Причем требования плохо формализованы и сложнопроверяемы. Так что по окончанию курсов QC сложнее «войти в айти».
Я думаю, это потому что у тестировщиков вайтивайти началось еще лет шесть назад. И как раз тогда позиция джуна/трейни тестировщика (не важно QA или QC) считалась эдакой халявной должностью для «полуголой бабы». Сейчас сложнее, да. Скоро и начать путь разраба будет архисложным (а судя по всему — уже).

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

Главное наличие горящего проекта и вчерашнего студента с не менее горящими глазами и светлой головой)

То есть видите- вы уже сильно ограничили шансы только пересечением множеств вчерашних студентов и горящих проектов:)

лучше программистом или верстальщиком..
Сейчас большинство не вошедших в айти тестировщиков изучают фронтенд зачем-то.

верстальщиком ,фронтендщиком..и т.п.

Через полгода нас ожидает нашествие джуниоров-фронтэндщиков. Хотя, думаю, многие намного дальше «основ HTML/CSS» не пройдут. Фронтэнд уже не тот, что был 5-10 лет назад.

Профессия QA идеально подходит для тех, кто хочет работать в IT, но не видит себя программистом

Кто-то еще, видит сдесь хоть намек на попытку определить что проще.

тем временем в ленте смежная точка зрения полнее раскрывается:
Свитчерам в IT

Пробовал на junior QA пойти пока в универе учился. Был с позором изгнан с собеседования, английский кстати и не спрашивали тогда.

Ну и к тому же у программиста и тестировщика может быть (и как правило есть) еще и разный менталитет/характер...экстраверту-холерику например в тестеры ...бедная команда будет, а програмистом ничего, можно жить. Ну и запрограмировать новую фичу (или даже пофиксить багу но красиво и без регрешенов) часто работает подход день потерять потом за час долететь. И тут чел может два дня «ничего» не делать а потом раз и готово. В тестировании более «линейно» и брать туда чела который может на несколько часов уйти в нирвану низзя (в програмера можно если в итоге есть резалт после нирван :) ) более трбовательно к пунктуальности и внимательности (ибо часто тестер, иногда даже джун-миддл — последний бастион проверки лажи, помнится в Материалайзе случай был, локализацию после минорного исправления в несвязной вроде области не проверили...а оно даже не устанавливалось...ох потом шухер был, «братья» лично QA перетрахивали...)

В целом из плохого/неудавшегося девелопера сосвем НЕ гарантия что будет лучший тестер. Так что заголовок немного того...

ЗЫ: сам в тестеры попал когда шел на CAD-инженера :) хотя до того был опыт программирования и тестирования «для себя» (вообще мы научные комплекс делали и сами их програмили и тестили)

В целом из плохого/неудавшегося девелопера сосвем НЕ гарантия что будет лучший тестер.
конечно ж нет.
скорее, наоборот.
если человек выбирает методом «попробую и посмотрю», то это говорит о проблемах с системностью. и тогда что там, что там, будет очень тяжело.
это говорит о проблемах с системностью
С чего это вдруг? Только единицы людей себя настолько хорошо знают сразу, чем они больше хотят заниматься. Обычно человек себя ищет..Попробовал, например, дизайн -не то ,верстка — не то, девелопер -не то. О май гад, — QA -подходит, у меня же было деструктивное мышление все компы всегда зависали ,программы вылетали, красиво пишу..
экстраверту-холерику например в тестеры ...бедная команда будет, а програмистом ничего
Что ваша фраза значит?
Тестировщику лучше быть холериком-экстравертом, или программистом, и почему? А то эти многоточия сбивают с толку)

Не сочтите за троллинг, но вспомнилась фраза:
«Не везет в карты — в любовь даже и не суйся!»

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

ну, я не HR Manager, могу сказать только про собеседования на которых был и о которых рассказывали соседи. В том числе, о людях из внутренних курсов.
Поделитесь своим опытом, что ли.

Требования к мануалу джуниору на самом деле минимальные. Уверенное знание основ, сообразительность и желание работать — вот пожалуй и все. И если с первым все понятно, то как проверить второе и третье качество — вопрос открытый. Поэтому, процесс отбора как правило весьма субъективен.

Да уж, я как прошел курсы в октябре на manual QA, так до сих пор даже приглашений на собеседования не поступало. Уже и автоматизацию познаю, но чую, что я быстрее выучу джаву и найду по ней работу, чем стану тестеровщиком(если вообще им стану) :)

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

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

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

Если прокрутить страницу до середины и сделать рефреш, верхняя плашка появляется не сразу, а через 5 секунд

Я не знаю почему я запостил это здесь

Гарна спроба, але — все рівно ні.

скриптам тоже надо время на загрузку

если такие требования предъявляются к джун-куа, то откуда тогда берутся таски в стиле «сделать за.б.сь»?

Профессия QA идеально подходит для тех, кто хочет работать в IT,
Потом читаешь баги от таких @"хочет работать".... и просто рыдаешь :)))))
А воспроизвести их это вообще отдельный квест :)))

Хотел было написать на практически каждое предложение, написанное автором, почему многое, так скажем, не совсем верно... А потом подумал что в интернете все равно кто-то всегда не прав, но, тем не менее, все имеют право на мнение. Пусть так и будет :)

Ограничусь парой ремарок:
— Порог входа ниже, чем в «любого» программиста. Он даже ниже чем в любой язык программирования как в таковой. Нравится вам это или нет — это факт.
— 95% вакансии на Junior QA не постят, подумайте почему.
— Junior QA, QA Trainee/Intern и QA после курсов (и смотря после каких) — очень разные QA-и.
— Количество «желающих» не создает большой конкуренции, так как 90-95% от всех желающих — на 3 головы ниже чем те 5% из общей массы, что получают работу, так как действительно обладают нужными знаниями и умениями. Проблема компаний — найти эти 5% в «массе», проблема новичков — не умение правильно «помочь» компаниям их найти (начиная с грамотно составленного/отправленного CV, заканчивая ленью).
— Фраза «не тянешь на программиста — иди в QA» имеет такой же смысл как и фразы «не тянешь Java? — иди в PHP» «не тянешь на слесаря? — иди водопроводчиком» «не тянешь на механика СТО? — иди водителем» — надеюсь, моя метафора ясна.

P.S.:
Все кто идут в QA за «деньгами» или являются проф. непригодными по тем или иным причинам, туда доходят редко, особенно сейчас. Не переживайте за них :)

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

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

Да но что плохого хотеть заработать денег и для этого «идти в айти»?

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

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

Ну эта проблема в основном джунов касается, и то только тех, кто без ВО -компьютер сайенс. Если вы уже «в айти», то вам вряд ли будут уже задавать такие вопросы:)

когда есть ICTQB-сертификат
ISTQB — International Software Testing Qualifications Board

А какая связь между фразой

Профессия QA идеально подходит для тех, кто хочет работать в IT, но не видит себя программистом
и заголовком
Не тянешь на программиста — иди в QA?

?
По-моему «не видит» и «не тянешь» это несколько разные выражения.
«Не видит» = не хочет; не нравится; сам считает, что это не его тип деятельности
«Не тянет» = не может
ИМХО «Не видит» <> «Не тянет»
Джуну QC сложно продемонстрировать навыки
Берешь тестируешь любой понравившийся сайт, создаешь тест план, делаешь баг-репорты, тестируешь на уязвимости, соответсвие стандартам и т.д. Результат можно залить на тот же github :)

вы сами так делали? или нанимали людей, которые так делали?

Я знаю людей, которые так делали (правда без github). И успешно уже работают.

а еще можно багрепорты клепать в опенсорс проекты

создаешь тест план
Такое требование на синьора, сэр

Тут можно поспорить. Но суть не в этом. Кто хочет — тот найдёт, как продемонстрировать свои умения и желание развиваться.

У меня студенты на курсе делают ;)
Не так как делают Senior-ы и уже по «живому» продукту, но тем не менее

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

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

Боюсь умений для анализа аутпута работы тулзы не хватит, ведь не всё записи — реальные уязвимости.
Хотя да, возможно даже сгенеренный авто-отчет будет джуну плюсом.

Каково же было мое удивление, когда увидел свой созданный мем здесь! Я его еще сочинил когда сам проходил курс тестирования ПО :)

Круто вот уж не думал что найдется автор

он уже разлетелся по всем рунетам и юанетам :)

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

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

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

Кто ж поначалу в нюансах разбирается? Все врачи в белых халатах на одно лицо. Все полисмены на одно лицо. Все тестировщики на два лица.

А некоторые думают что начнут с тестировщика из-за «низкого порога», а потом перейдут в девелоперов.

Что мешает перейти? :)

Как минимум отсутствие понимания кто и что делает и чем хочется заниматься. А отсюда вытекает вопрос что и как учить и сколько лет у меня это займет чтобы устроиться на джуна. В qa в этом плане проще.

Свобода порождает проблему выбора

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

в куа за 1 месяц работы понимаешь — чем не хотите заниматься

а именно мануальным тестированием =)

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

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

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

Ну да, тестировать сложнее чем создавать. Полностью согласен. Абсолютно!

вы какими показателями меряете?

Изначально замечу. Я очень уважаю тестеров и считаю их работу по важности равной девелоперам. Но по количеству инфы которую нужно знать для «входа» мне кажется девам сложнее.

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

Страницами, примерами, принципами которые нужно понимать, разными технологиями.

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

Вот часто пишут/говорят про «вход» или «порог входа/вхождения». Например «в php низкий порог входа». А что такое «вход»? Hello World это уже вход или ещё нет? RESTful API — это вход или ещё нет или уже нет?

Вход это когда вы вошли, а не стучите в закрытую дверь. Так понятно?)

«Порог входа» — объем необходимых знаний, умений и опыта для получения начальной должности в профессии.
Так понятнее?

Да, так понятнее. Осталось только точно обмерить эту цифру для дева и куа

Теперь я не понимаю о чем вы говорите...

я думаю, имелся введу некий коэффициент. К примеру: если коэффициент порога входа дева равен 1.0, то какой коэффициент порога входа на куа. Это если я правильно понял оратора выше :)

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

в ваших словах я вижу что-то типа «двор мести может каждый, потому будем требовать обязательное высшее».
какой смысл в искусственном повышении порога? неужели, вы как HR не слышали про такой термин как overqualified?

в ваших словах я вижу что-то типа «двор мести может каждый, потому будем требовать обязательное высшее»
Неправильно, правильно будет так: «Двор мести желающих много, поэтому будем требовать обязательное высшее». Но это тоже неверно, так как приравнивать куа к дворнику некорректно, а высшее образование есть нынче у всех.
какой смысл в искусственном повышении порога? неужели, вы как HR не слышали про такой термин как overqualified?
Повышать порог можно по разному. Самое банальное и часто используемое и при этом самое неправильное — это завышение требований к опыту и владению технологиями. Это действительно может привести к overqualified. Но зачастую к этому вопросу подходят более субъективно и/или творчески. Вплоть до фейс-контроля. Я не говорю, что это правильно. Просто констатирую факты.
Но это тоже неверно, так как приравнивать куа к дворнику некорректно
омг, приравняйте девелопера к дворнику. или HR.
Самое банальное и часто используемое и при этом самое неправильное — это завышение требований к опыту и владению технологиями
у вас-то как это наблюдается?
действительно, берут на джунов тех, кто раньше был бы синьором?
у вас-то как это наблюдается?действительно, берут на джунов тех, кто раньше был бы синьором?
Я ведь написала — это плохая практика. Лишних джунов надо отсеивать другими способами.
высшее образование есть нынче у всех
Я бы не был так уверен.
Вплоть до фейс-контроля
Это всмысле если размер... меньше третьего- то такая QA не подходит?

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

Джуниоров этим сильно не испугаешь

Можно ввести понятие отрицательной зп.
Чтоб платили за то что работают на реальном проекте....

ой что это я? это уже есть — «курсы QA» называется

Где Вы видели на курсах реальные проекты?

В киеве, 5 лет назад в Люксе один предприимчивый парниша тестировал реальный проект на «своих курсах» студентами курсов.
Потом давался сертификат- типа опыт 6 месяцев стажировки на реальном боевом проекте

Странно, что эту тему никто не развивает

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

Когда 20 человек тестируют одну формочку пусть даже абсолютно реального проекта (которую до них тестировало еще 80 человек) — такую работу сложно назвать реальной.

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

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

Может это и к лучшему, что таких курсов мало?
А то представьте- будет у вас 2000 джунов, и каждый с опытом работы -как их потом отбирать?)

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

Тестирование верстки — это часть нефункционального тестирования:
xiper.net/...in-general/testing-layout
habrahabr.ru/post/114256

«создавать».. какие громкие слова

будет комфортно жить под крылом тимлида
Получается, что порог входа ниже («еще ниже, еще!») а скилы — какие-то совсем уж не технические )))

Не тянешь в QA — иди в PMы

не тянешь PMа- сразу в CEO :-)

А я смотрю тебя сильно зацепила моя история :) до сих пор оправится не можешь, раз все время вспоминаешь? :)
И да, я PM. И да, у меня получается, и теперь у меня в команде 4 девелопера и 1 дизайнер :) И у меня все хорошо. И ребята зарабатывают и клиенты довольны, и продукт качественный.
Может ты уже успокоишься? Хотя вряд ли. Теперь тебя будет еще больше бадхердить. :)

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

ничего себе! по фото определил всю суть! срочно на битву экстрасенсов в команду к Пахому, он тоже талант, вы вместе горы свернете, он еще и покушать приносить будет

Это какой-то новый тренд, да :D А лучше сразу в СЕО/CОО — там платят больше!

tl; dr; От новичка QC ожидают большего, чем от новичка-разработчика. Причем требования плохо формализованы и сложнопроверяемы. Так что по окончанию курсов QC сложнее «войти в айти».

якщо замінити QC на Dev, то можна довго плакатися про необхідність проектів і коду і знання 100500 технологій і ще 100500 різних речей, і прийти до висновку, що Dev важче, ніж QC

ну ти зрозумів натяк

що Dev важче, ніж QC
я не сравниваю направления. я сравниваю процесс “входа”. как вы собеседуете джуна QC? можете своим опытом поделиться?
или это умозрительное исключительно гипотетическое заявление?

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

я не сравниваю направления. я сравниваю процесс «входа».

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

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

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

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

куа не співбесідую, але перелічені питання мені на SE позицію задавали (про тестування). але не розумію, наскільки це релевантно, звучить як «сперва добейся»

ти “входом” називаєш
окей, меня, кстати, это клише напрягает. у каждого свое понимание “входа”.

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

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

куа не співбесідую, але перелічені питання мені на SE позицію задавали (про тестування)
вот этого вообще не понял. тем более, не понял, чему это по-вашему может быть “релевантно” :(

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

то наверняка их не сильно пугают сложности после самого входа.
курсы — это еще не «вход».

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

Пожалуйста, не «идите в QC» только потому, что вам рассказали, какой там низкий порог входа

dou.ua/...les/qa-engineer-position — 118 тыс. просмотров :)
(На втором месте (как и в трендах) dou.ua/...project-manager-position, 84 тыс. просмотров).

А еще вроде больше конкуренция

Stop manual testing! Automate it!

Интересует ваше мнение — всегда ли рационально автоматизировать тесты? А что они найдут? А на каком этапе? А если проект под «мобилочки» на 3 месяца — тоже рационально? Приёмку фичей тоже автомейтить следует? А что если считать по человекочасам * рейт?
Это я всё к тому, что совсем уж «stop», хоть и распространённая (в особенности среди гуру /* или их себя считающими */), но ошибочная позиция.

Да я так... Подразнить;)

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