Comments 30
Следующий вопрос чаще всего ставит в тупик.
Есть страница логина. Пользователь вводит корректные данные для авторизации и кликает на кнопку входа. Что происходит в браузере в этот момент? Почему последующие действия с сайтом не требуют повторной авторизации?
Всегда задаю этот вопрос для определения уровня понимания работы браузера у тестировщиков которые указывают что работают с вебом, не важно ручные или авто. И да, отвечают ну очень крайне малое количество людей :(
Вообще техническое рахвитие у тестировщиков по моему опыту крайне слабое, большинство становятся «незаменимымыми знакоками продукта». Но их знания бизнес логики их текущего проекта не обеспечивают им ту сумму котороую они обычно хотят.
По моим наблюдениям люди с 10+ годами опыта на собеседованиях отвечают хуже кандидатов 3+. Они «застывают» на каком-то этапе технической компетенции и как вы выразились, почивают на лаврах «незаменимых знатоков продукта».
Проблема с такими кандидатами — желание учиться и переучиваться. Они уже привыкли забивать гвозди микроскопом.
Проблема с такими кандидатами — желание учиться и переучиваться. Они уже привыкли забивать гвозди микроскопом.
1) Статья не имеет смысла, без указания зп, которую вы предлагаете тестеру. Ибо за одни деньги тебе будет и динамика параметров, и степобджекты и пейджобжекты, и конвекторы и прочие сладости хорошего проекта (да еще разрабов будет пинать, что его рест-апи для хвостов не очень качественный). А за другие деньги будет хорошо, если человек знает базовый html/css/js.
2) Обычно нанимается один хороший QA-лид, который делает весь каркас проекта и задает планку качества, а остальные тестеры его расширяют под строгим код ревью. Требовать, чтобы каждый мог также четко, как QA-лид — идиотизм.
3) Примеры из статьи — бесполезные. Ибо один раз хватит человеку показать, как надо (а еще лучше дать пачку готовых методов), и он будет писать так, как нужно.
4) На обсуждении новой фичи, он готов дать фидбек, потому что понимает, как новая фича интегрируется с существующими компонентами.
— Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.
Такое ощущение, что писал статью человек, который в жизни не отвечал за QA в крупном проекте, и не работал с командой тестеров, если их больше 2-3.
2) Обычно нанимается один хороший QA-лид, который делает весь каркас проекта и задает планку качества, а остальные тестеры его расширяют под строгим код ревью. Требовать, чтобы каждый мог также четко, как QA-лид — идиотизм.
3) Примеры из статьи — бесполезные. Ибо один раз хватит человеку показать, как надо (а еще лучше дать пачку готовых методов), и он будет писать так, как нужно.
4) На обсуждении новой фичи, он готов дать фидбек, потому что понимает, как новая фича интегрируется с существующими компонентами.
— Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.
Такое ощущение, что писал статью человек, который в жизни не отвечал за QA в крупном проекте, и не работал с командой тестеров, если их больше 2-3.
Я что-то пропустил упоминание размеров проекта.
P.S. Да, это очень печально, да это не правильно. Но что поделать — обычно и правильно это все же не одно и то же.
Обычно нанимается один хороший QA-лид, который делает весь каркас проекта и задает планку качества, а остальные тестеры его расширяют под строгим код ревью.Если под «обычно» подразумевается «чаще всего», то обычно QA отдел начинается и заканчивается этим самым QA-лидом. Зачастую он же становится техническим писателем, и, как следствие, обладателем наиболее полного представления о бизнес-логике всего проекта. Что приводит нас к пункту 4.
P.S. Да, это очень печально, да это не правильно. Но что поделать — обычно и правильно это все же не одно и то же.
Да тут ситуация как с разработкой — 4 сениора, 7 мидлов или десяток джунов?
Лучше взять одного крутого, четверых послабее, и двух почти начинающих.
Лучше взять одного крутого, четверых послабее, и двух почти начинающих.
Джоэл Спольски в своей книге «О программировании» топит за то, что лучше не нанять подходящего специалиста, чем нанять не подходящего. К сожалению, это так.
Конечный результат от четырёх толковых чуваков лучше, даже если кого-то толкового на этапе интервью отсеют.
Конечный результат от четырёх толковых чуваков лучше, даже если кого-то толкового на этапе интервью отсеют.
Ага, пусть текущий программист лучше сляжет от переработок на 3 должности, а после больницы уйдёт подальше, пока ещё жив. /sarcasm
IMHO, конечный результат больше зависит от процессов: если выстроены процессы и любого программиста сначала натыкают в соглашения по коду, потом в собранную библиотеку методов и классов под проект и после — в гит с готовыми тестами и скажут «делай не хуже, если что-подходи, код-ревью по четвергам» — то нужно быть совсем уж неподходящим человеком, чтоб сделать плохо.
Ну а если галера снизу затоплена, посредине — уже горит, а сверху догружают техдолг — нужен суперджедай, чтоб разгрезти всё и сразу.
IMHO, конечный результат больше зависит от процессов: если выстроены процессы и любого программиста сначала натыкают в соглашения по коду, потом в собранную библиотеку методов и классов под проект и после — в гит с готовыми тестами и скажут «делай не хуже, если что-подходи, код-ревью по четвергам» — то нужно быть совсем уж неподходящим человеком, чтоб сделать плохо.
Ну а если галера снизу затоплена, посредине — уже горит, а сверху догружают техдолг — нужен суперджедай, чтоб разгрезти всё и сразу.
1. На инженерные вакансии в компании ± одинаковые рейты. В нашем случае предлагается зарплата middle/senior разработчика.
Трюк в том, что на эти условия всё равно не найти ковбоев, стреляющих из двух рук.
2. Большие компании могут себе позволить обучение, взращивание специалистов внутри. Мы ищем опытных и самостоятельных специалистов.
Предположим, уровень программирования у человека хромает, это наживное. Но что делать с первыми двумя пунктами? Мне не кажется сверх-требованием просить рассказать архитектуру проекта и как браузер запросы гоняет. Это базовые вещи.
3. Значит мне всё время встречаются неправильные люди. Они где-то учатся плохим практикам и продолжают тащить свои знания сквозь годы опыта.
4. У тестировщика в голове есть целостная картина о продукте. Если к этому добавить технический бэкграунд, он готов дать ценный фидбек о новой фиче. Потому что у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.
Трюк в том, что на эти условия всё равно не найти ковбоев, стреляющих из двух рук.
2. Большие компании могут себе позволить обучение, взращивание специалистов внутри. Мы ищем опытных и самостоятельных специалистов.
Предположим, уровень программирования у человека хромает, это наживное. Но что делать с первыми двумя пунктами? Мне не кажется сверх-требованием просить рассказать архитектуру проекта и как браузер запросы гоняет. Это базовые вещи.
один раз хватит человеку показать, как надо
3. Значит мне всё время встречаются неправильные люди. Они где-то учатся плохим практикам и продолжают тащить свои знания сквозь годы опыта.
А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.
4. У тестировщика в голове есть целостная картина о продукте. Если к этому добавить технический бэкграунд, он готов дать ценный фидбек о новой фиче. Потому что у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.
У тестировщика в голове есть целостная картина о продукте… у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.
вы только не забывайте, пожалуйста, что это специфика вашего проекта/компании.
А у многих команды QA+front+(1-3)back пилят свою часть, и знаний о продукте в этом случае у тестировщика и у разработчика примерно поровну… отсюда и столько удивления )
Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.
У некоторых аналитики и тестировщики — это одна сущность. Конечно, кампании сами себе злые буратины в таком случае.
«Ронда» так тестировщиков нанимает ещё с 2016. В вакансии пишут " ничего не надо". А по факту, как давай меня гонять по всяким алгоритмам, прям будто собеседование в гугль на senior developer
Есть некоторая грань на которой лучше нанять разработчика, который будет тестировать свой код, чем нанимать плохо пишущего QA инженера.
Требовать от простолюдина качеств благородного дона, да ещё и за простолюдинскую зярпляту, это знаете…
Бизнес требует? Ну тогда и решение проблем должно быть чисто управленческое, выше в комментариях адекватный пример приведен.
Ведь со всеми вашими хотелками, сотрудник уже не простолюдин, но дон благородный, требующий соответствующего обхождения.
Он ещё и прибавку потребует за вредность и унылость производства :-)
Я не верю, что с таким подходом инженер придумает все возможные тестовые сценарии. Если знать внутреннее устройство продукта и читать код, можно избежать дублирования тестов на высоких уровнях пирамиды тестирования.
Забавно, что это ровно основной аргумент против того, чтобы программист сам тестировал свой код) Мол раз ты знаешь свой код, значит будешь писать тесты так, чтобы они этому коду соответствовали)
Когда я устраивался тестировщиком, пять лет назад, были еще места для «ручных» тестировщиков. Сегодня к навыкам тестирования требуется и навык автоматизации. «Сбывается» то, о чем давно говорит James Bach. Нет никакого «ручного» и «автоматизированного» тестирования. Есть тестирование, и тестировщик, который, должен (постоянно) развивать себя, и пользоватья инструментами, там где это необходимо.
Должен сказать, ручные тестировщики смотрятся сегодня чуднó. Даже имея сильнейшее искреннее желание, они не в состоянии держать темп и развить необходимой эффективности, учитывая экспоненциальный рост сложности приложений, и повышение частоты изменений. Бизнес не имеет права идти на уступки в этом плане, иначе он отстанет от рынка. Я бы вообще упразднил такую должность.
Иметь и ручных тестировщиков и автоматизаторов вообще мрак. Приходится обьяснять, что у нас автоматизированно, сверять ручные тесты и обьяснять почему их нельзя автоматизировать. Столько ненужной канители. Как было бы удобно, если бы все имели одинаковый навык, не пришлось бы ничего никому обьяснять и ни с кем цацкаться. Обьем работы виден. Сдал код — значит работаешь. Нет кода — или затык или балду гоняешь.
Многие проблемы в приложении вскрываются когда начинаешь автоматизировать. При ручном тестировании, заложенные в человеке эвристики обходят эти проблемы. А автомат бездушен, беспристрастен, и тем хорош. Он всегда делает одно и то же. Он не закроет «мешающее» всплывающее окошко, а остановится и вынудит тебя выяснить в чем дело. И это заставит тебя узнать что-то новое о приложении. Знание приложения — первичное знание тестировщика.
Мои автоматизированные тесты «знают» о приложении больше, чем наши ручные тестировщики. А о старых версиях знают иногда больше чем разработчики. Я всегда могу сказать, что было протестированно и как. Это такая возможность. Нельзя ей пренебрегать.
А какие бы они тест-кейсы писали если бы умели автоматизировать. Машина все понимает однозначно, программист все понимает однозначно. Как удобно. Зачем эта архаичные многословные романы в экселе. А еще хуже немногословные огрызки с потугой на тест-кейсы. Некоторые сляпаны так, что другой человек по написанному не сможет его выполнить.
Вы не поймите неправильно. Я за правильное применение человеческой силы на производстве. Когда у тебя есть автоматизация, ты можешь заняться ручной проверкой особенно интересных и важных, но сложно автоматизируемых сценариев. Это интеллектуальный труд. Когда у тебя нет автоматизации, ты елозишь по регрессии, и сжигаешь этим человеческий ресурс. Простите, но по большому счету, ручное тестирование регрессии, это унизительное занятие для человека, как живого существа, в сравнении с его реальным умственным потенциалом.
Должен сказать, ручные тестировщики смотрятся сегодня чуднó. Даже имея сильнейшее искреннее желание, они не в состоянии держать темп и развить необходимой эффективности, учитывая экспоненциальный рост сложности приложений, и повышение частоты изменений. Бизнес не имеет права идти на уступки в этом плане, иначе он отстанет от рынка. Я бы вообще упразднил такую должность.
Иметь и ручных тестировщиков и автоматизаторов вообще мрак. Приходится обьяснять, что у нас автоматизированно, сверять ручные тесты и обьяснять почему их нельзя автоматизировать. Столько ненужной канители. Как было бы удобно, если бы все имели одинаковый навык, не пришлось бы ничего никому обьяснять и ни с кем цацкаться. Обьем работы виден. Сдал код — значит работаешь. Нет кода — или затык или балду гоняешь.
Многие проблемы в приложении вскрываются когда начинаешь автоматизировать. При ручном тестировании, заложенные в человеке эвристики обходят эти проблемы. А автомат бездушен, беспристрастен, и тем хорош. Он всегда делает одно и то же. Он не закроет «мешающее» всплывающее окошко, а остановится и вынудит тебя выяснить в чем дело. И это заставит тебя узнать что-то новое о приложении. Знание приложения — первичное знание тестировщика.
Мои автоматизированные тесты «знают» о приложении больше, чем наши ручные тестировщики. А о старых версиях знают иногда больше чем разработчики. Я всегда могу сказать, что было протестированно и как. Это такая возможность. Нельзя ей пренебрегать.
А какие бы они тест-кейсы писали если бы умели автоматизировать. Машина все понимает однозначно, программист все понимает однозначно. Как удобно. Зачем эта архаичные многословные романы в экселе. А еще хуже немногословные огрызки с потугой на тест-кейсы. Некоторые сляпаны так, что другой человек по написанному не сможет его выполнить.
Вы не поймите неправильно. Я за правильное применение человеческой силы на производстве. Когда у тебя есть автоматизация, ты можешь заняться ручной проверкой особенно интересных и важных, но сложно автоматизируемых сценариев. Это интеллектуальный труд. Когда у тебя нет автоматизации, ты елозишь по регрессии, и сжигаешь этим человеческий ресурс. Простите, но по большому счету, ручное тестирование регрессии, это унизительное занятие для человека, как живого существа, в сравнении с его реальным умственным потенциалом.
Должен сказать, ручные тестировщики смотрятся сегодня чуднó.
…
Я бы вообще упразднил такую должность.
Exploratory testing в качестве основной задачи, но не для регрессии, согласен.
Когда у тебя нет автоматизации, ты елозишь по регрессии, и сжигаешь этим человеческий ресурс.
Самое печальное, у человека нет времени заниматься чем-то интересным и прокачивать навыки. Тут как в известной книге:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
По наблюдениям годы опыта кандидата никак не коррелирует с количеством пробеловНа какую зп искали?
Большинство обозначенных проблем покрываются либо наймом разработчика на соответствующие задачи, либо наймом адекватного тестировщика, способного на освоение новых инструментов. В поиске такого тестировщика и состоит суть собеседования. Даже если кандидат практически не соприкасался с какими-либо задачами, всегда есть возможность прощупать как работают его мозги на наводящих хайлэвельных вопросах.
Те технические вопросы, которыми вы попрекайте, решаются элементарными код ревью, которые, судя опять-таки по вашей статье в вашей команде не особо практикуются, иначе и таких претензий бы не было. Элементарно спустя несколько код ревью все приноравливаются писать код так как правильно\оптимизировано\логично\понятно (ну либо начинаются интеллектуальные столкновения, которые опять таки решаются большинством голосов).
Другое дело, если нет времени на такого тестировщика, которому можно выделить время на вливание в инструментарий, но уверен, все решаемо с помощью зп.
Целиком поддерживаю Terras c его комментом.
А вам желаю определиться с тем, кого же вы в итоге ищите.
Те технические вопросы, которыми вы попрекайте, решаются элементарными код ревью, которые, судя опять-таки по вашей статье в вашей команде не особо практикуются, иначе и таких претензий бы не было. Элементарно спустя несколько код ревью все приноравливаются писать код так как правильно\оптимизировано\логично\понятно (ну либо начинаются интеллектуальные столкновения, которые опять таки решаются большинством голосов).
Другое дело, если нет времени на такого тестировщика, которому можно выделить время на вливание в инструментарий, но уверен, все решаемо с помощью зп.
Целиком поддерживаю Terras c его комментом.
А вам желаю определиться с тем, кого же вы в итоге ищите.
Полностью согласен с автором статьи.
Технический бекграунд большинства QA инженеров (особенно долго работающих в аутсорсе) очень и очень ограничен.
Пару комментариев.
1. Несомненно все упирается в ЗП. Если хочется нанять кандидата — который за 5 минут проанализирует и нарисует UML диаграмму всего работающего приложения и распишет где-что может потенциально отвалиться (плюс может это и автотестами покрыть) — то такой специалист будет стоить явно не 200$.
2. Очень много кто из работающих тестировщиков понимает, что все это надо знать. Но он уже «прижился» в своей компании — и спокойно плывет по течению. Ему не нужно учиться новому, ему не нужно улучшать скиллы (мотивации нет). Просто расслабься и работай. Обратная сторона раскрывается — когда такой кандидат выходит на поиски новой работы и осознает, что его 5+/10+ лет опыта в узкопрофильной банковской системе мало кому интересны.
3. Пока компании берут тестировщиков на разные деньги и с разными уровнем — такие люди и будут. Для отбора «топовых» кандидатов — надо работать над технологическим брендом компании, внимательно собеседовать, давать тестовое задание и тд.
4. Курсы тестирования как раз и способствуют появлению множества таких «знаю только черный ящик и селинум => хочу много денег» тестировщиков на рынке. Да еще сразу — после трех месяцев обучения.
Технический бекграунд большинства QA инженеров (особенно долго работающих в аутсорсе) очень и очень ограничен.
Пару комментариев.
1. Несомненно все упирается в ЗП. Если хочется нанять кандидата — который за 5 минут проанализирует и нарисует UML диаграмму всего работающего приложения и распишет где-что может потенциально отвалиться (плюс может это и автотестами покрыть) — то такой специалист будет стоить явно не 200$.
2. Очень много кто из работающих тестировщиков понимает, что все это надо знать. Но он уже «прижился» в своей компании — и спокойно плывет по течению. Ему не нужно учиться новому, ему не нужно улучшать скиллы (мотивации нет). Просто расслабься и работай. Обратная сторона раскрывается — когда такой кандидат выходит на поиски новой работы и осознает, что его 5+/10+ лет опыта в узкопрофильной банковской системе мало кому интересны.
3. Пока компании берут тестировщиков на разные деньги и с разными уровнем — такие люди и будут. Для отбора «топовых» кандидатов — надо работать над технологическим брендом компании, внимательно собеседовать, давать тестовое задание и тд.
4. Курсы тестирования как раз и способствуют появлению множества таких «знаю только черный ящик и селинум => хочу много денег» тестировщиков на рынке. Да еще сразу — после трех месяцев обучения.
Нынче разработчика под такие требования найдёшь не сразу, а тут от QA их хотят :-D
Мне в целом нравится подход когда QA в продуктовой команде и проводит ручное тестирование и пишет тесты на готовую стори/баг из своего спринта (при условии что есть готовый фреймворк, который написал кто-то из AQA/SDET).
Это правда надо в definition of done задачи закладывать и включать в оценку задач спринта, да и часть тестов (особенно unit, которых больше всего в пирамиде) должны разработчики писать, а qa могут подсказать какие-то дополнительные проверки в них.
Но чаще видел когда автоматизаторы отдельно, а ручное тестирование отдельно.
Это правда надо в definition of done задачи закладывать и включать в оценку задач спринта, да и часть тестов (особенно unit, которых больше всего в пирамиде) должны разработчики писать, а qa могут подсказать какие-то дополнительные проверки в них.
Но чаще видел когда автоматизаторы отдельно, а ручное тестирование отдельно.
Вы описали фактически разработчика, это уже не QA manual или auto, это уже Developer in test. Вот если я допустим такой тестировщик как вы описали то зачем мне париться и идти в тестеры если у разработчика и вакансий больше, и прав и уважения и денег. И программист у всех на слуху, их релоцируют даже. Все маломальски технически грамотные QA переходят в разработку, хотят они того или нет. Остаются мануалы, автоматизаторы-гоняторы постманов и селенидов.
Первые два пункта не о разработчике, последний про автоматизацию с использованием готовых инструментов. SDET в моём понимании делает инструменты для тестирования.
У каждого свои приоритеты. Если нет уважения, есть два варианта: либо не та компания, либо не успели завоевать авторитет.
Возможно, не все компании готовы платить. Это другая проблема.
… вакансий больше, и прав и уважения и денег.
У каждого свои приоритеты. Если нет уважения, есть два варианта: либо не та компания, либо не успели завоевать авторитет.
Все маломальски технически грамотные QA переходят в разработку, хотят они того или нет.
Возможно, не все компании готовы платить. Это другая проблема.
Знаю несколько отличных тестеров с многолетним (лет около 15) опытом, которых даже +40% зп не переманили в разработку: девушкам не хочется постоянно писать код, а писать тесты — наоборот.
Спрашивал — чем написание кода в QTP/Selenium/Rational robot лучше, чем та же разработка, отвечают, что сменой занятий: надоел код — тестишь ручками, надоело всё — смотришь сериал. Ну а денег и так хватает.
Спрашивал — чем написание кода в QTP/Selenium/Rational robot лучше, чем та же разработка, отвечают, что сменой занятий: надоел код — тестишь ручками, надоело всё — смотришь сериал. Ну а денег и так хватает.
Sign up to leave a comment.
Тестировщики-гомеопаты или хронические проблемы найма