Pull to refresh

Comments 30

Следующий вопрос чаще всего ставит в тупик.
Есть страница логина. Пользователь вводит корректные данные для авторизации и кликает на кнопку входа. Что происходит в браузере в этот момент? Почему последующие действия с сайтом не требуют повторной авторизации?

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

Проблема с такими кандидатами — желание учиться и переучиваться. Они уже привыкли забивать гвозди микроскопом.
1) Статья не имеет смысла, без указания зп, которую вы предлагаете тестеру. Ибо за одни деньги тебе будет и динамика параметров, и степобджекты и пейджобжекты, и конвекторы и прочие сладости хорошего проекта (да еще разрабов будет пинать, что его рест-апи для хвостов не очень качественный). А за другие деньги будет хорошо, если человек знает базовый html/css/js.

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

3) Примеры из статьи — бесполезные. Ибо один раз хватит человеку показать, как надо (а еще лучше дать пачку готовых методов), и он будет писать так, как нужно.

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

— Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

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

P.S. Да, это очень печально, да это не правильно. Но что поделать — обычно и правильно это все же не одно и то же.
Требовать, чтобы каждый мог также четко, как QA-лид — идиотизм.

Можете раскрыть, почему вы так думаете?
На длительный проект, на мой взгляд, лучше нанять четверых крутых тестировщиков, чем десяток послабее.
Да тут ситуация как с разработкой — 4 сениора, 7 мидлов или десяток джунов?
Лучше взять одного крутого, четверых послабее, и двух почти начинающих.
Джоэл Спольски в своей книге «О программировании» топит за то, что лучше не нанять подходящего специалиста, чем нанять не подходящего. К сожалению, это так.
Конечный результат от четырёх толковых чуваков лучше, даже если кого-то толкового на этапе интервью отсеют.
Ага, пусть текущий программист лучше сляжет от переработок на 3 должности, а после больницы уйдёт подальше, пока ещё жив. /sarcasm
IMHO, конечный результат больше зависит от процессов: если выстроены процессы и любого программиста сначала натыкают в соглашения по коду, потом в собранную библиотеку методов и классов под проект и после — в гит с готовыми тестами и скажут «делай не хуже, если что-подходи, код-ревью по четвергам» — то нужно быть совсем уж неподходящим человеком, чтоб сделать плохо.
Ну а если галера снизу затоплена, посредине — уже горит, а сверху догружают техдолг — нужен суперджедай, чтоб разгрезти всё и сразу.
1. На инженерные вакансии в компании ± одинаковые рейты. В нашем случае предлагается зарплата middle/senior разработчика.
Трюк в том, что на эти условия всё равно не найти ковбоев, стреляющих из двух рук.

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

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

3. Значит мне всё время встречаются неправильные люди. Они где-то учатся плохим практикам и продолжают тащить свои знания сквозь годы опыта.

А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

4. У тестировщика в голове есть целостная картина о продукте. Если к этому добавить технический бэкграунд, он готов дать ценный фидбек о новой фиче. Потому что у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.
У тестировщика в голове есть целостная картина о продукте… у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.

вы только не забывайте, пожалуйста, что это специфика вашего проекта/компании.
А у многих команды QA+front+(1-3)back пилят свою часть, и знаний о продукте в этом случае у тестировщика и у разработчика примерно поровну… отсюда и столько удивления )
Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

У некоторых аналитики и тестировщики — это одна сущность. Конечно, кампании сами себе злые буратины в таком случае.

Я скажу больше. Менеджер проекта — аналитик, тестировщик, глава отдела по связям с клиентами, глава отдела по связям с общественностью. И да, в таких компаниях найти документацию для составления тестов актуальной версии программы — нельзя от слова «Agile в течении 6 лет».
«Ронда» так тестировщиков нанимает ещё с 2016. В вакансии пишут " ничего не надо". А по факту, как давай меня гонять по всяким алгоритмам, прям будто собеседование в гугль на senior developer
Есть некоторая грань на которой лучше нанять разработчика, который будет тестировать свой код, чем нанимать плохо пишущего QA инженера.
Согласен. Есть примеры, когда компания обходится без QA. Культура разработки, тесты, CI/CD — если всё присутствует, это круто.
В основном такой подход больше применим для разработки бэкенда, где тесты написать достаточно просто, а с UI и приложениями всё может быть не так очевидно и просто

Требовать от простолюдина качеств благородного дона, да ещё и за простолюдинскую зярпляту, это знаете…
Бизнес требует? Ну тогда и решение проблем должно быть чисто управленческое, выше в комментариях адекватный пример приведен.
Ведь со всеми вашими хотелками, сотрудник уже не простолюдин, но дон благородный, требующий соответствующего обхождения.
Он ещё и прибавку потребует за вредность и унылость производства :-)

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

Забавно, что это ровно основной аргумент против того, чтобы программист сам тестировал свой код) Мол раз ты знаешь свой код, значит будешь писать тесты так, чтобы они этому коду соответствовали)

Есть такой момент. В идеале отлавливается на код-ревью.
Когда я устраивался тестировщиком, пять лет назад, были еще места для «ручных» тестировщиков. Сегодня к навыкам тестирования требуется и навык автоматизации. «Сбывается» то, о чем давно говорит James Bach. Нет никакого «ручного» и «автоматизированного» тестирования. Есть тестирование, и тестировщик, который, должен (постоянно) развивать себя, и пользоватья инструментами, там где это необходимо.

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

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

Многие проблемы в приложении вскрываются когда начинаешь автоматизировать. При ручном тестировании, заложенные в человеке эвристики обходят эти проблемы. А автомат бездушен, беспристрастен, и тем хорош. Он всегда делает одно и то же. Он не закроет «мешающее» всплывающее окошко, а остановится и вынудит тебя выяснить в чем дело. И это заставит тебя узнать что-то новое о приложении. Знание приложения — первичное знание тестировщика.

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

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

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

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

Я бы вообще упразднил такую должность.

Exploratory testing в качестве основной задачи, но не для регрессии, согласен.

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

Самое печальное, у человека нет времени заниматься чем-то интересным и прокачивать навыки. Тут как в известной книге:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
По наблюдениям годы опыта кандидата никак не коррелирует с количеством пробелов
На какую зп искали?
На зарплату middle/senior разработчика.
Большинство обозначенных проблем покрываются либо наймом разработчика на соответствующие задачи, либо наймом адекватного тестировщика, способного на освоение новых инструментов. В поиске такого тестировщика и состоит суть собеседования. Даже если кандидат практически не соприкасался с какими-либо задачами, всегда есть возможность прощупать как работают его мозги на наводящих хайлэвельных вопросах.

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

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

Целиком поддерживаю Terras c его комментом.

А вам желаю определиться с тем, кого же вы в итоге ищите.
Полностью согласен с автором статьи.
Технический бекграунд большинства QA инженеров (особенно долго работающих в аутсорсе) очень и очень ограничен.
Пару комментариев.
1. Несомненно все упирается в ЗП. Если хочется нанять кандидата — который за 5 минут проанализирует и нарисует UML диаграмму всего работающего приложения и распишет где-что может потенциально отвалиться (плюс может это и автотестами покрыть) — то такой специалист будет стоить явно не 200$.
2. Очень много кто из работающих тестировщиков понимает, что все это надо знать. Но он уже «прижился» в своей компании — и спокойно плывет по течению. Ему не нужно учиться новому, ему не нужно улучшать скиллы (мотивации нет). Просто расслабься и работай. Обратная сторона раскрывается — когда такой кандидат выходит на поиски новой работы и осознает, что его 5+/10+ лет опыта в узкопрофильной банковской системе мало кому интересны.
3. Пока компании берут тестировщиков на разные деньги и с разными уровнем — такие люди и будут. Для отбора «топовых» кандидатов — надо работать над технологическим брендом компании, внимательно собеседовать, давать тестовое задание и тд.
4. Курсы тестирования как раз и способствуют появлению множества таких «знаю только черный ящик и селинум => хочу много денег» тестировщиков на рынке. Да еще сразу — после трех месяцев обучения.
Нынче разработчика под такие требования найдёшь не сразу, а тут от QA их хотят :-D
Мне в целом нравится подход когда QA в продуктовой команде и проводит ручное тестирование и пишет тесты на готовую стори/баг из своего спринта (при условии что есть готовый фреймворк, который написал кто-то из AQA/SDET).

Это правда надо в definition of done задачи закладывать и включать в оценку задач спринта, да и часть тестов (особенно unit, которых больше всего в пирамиде) должны разработчики писать, а qa могут подсказать какие-то дополнительные проверки в них.

Но чаще видел когда автоматизаторы отдельно, а ручное тестирование отдельно.
Вы описали фактически разработчика, это уже не QA manual или auto, это уже Developer in test. Вот если я допустим такой тестировщик как вы описали то зачем мне париться и идти в тестеры если у разработчика и вакансий больше, и прав и уважения и денег. И программист у всех на слуху, их релоцируют даже. Все маломальски технически грамотные QA переходят в разработку, хотят они того или нет. Остаются мануалы, автоматизаторы-гоняторы постманов и селенидов.
Первые два пункта не о разработчике, последний про автоматизацию с использованием готовых инструментов. SDET в моём понимании делает инструменты для тестирования.

… вакансий больше, и прав и уважения и денег.

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

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

Возможно, не все компании готовы платить. Это другая проблема.
Знаю несколько отличных тестеров с многолетним (лет около 15) опытом, которых даже +40% зп не переманили в разработку: девушкам не хочется постоянно писать код, а писать тесты — наоборот.
Спрашивал — чем написание кода в QTP/Selenium/Rational robot лучше, чем та же разработка, отвечают, что сменой занятий: надоел код — тестишь ручками, надоело всё — смотришь сериал. Ну а денег и так хватает.
Sign up to leave a comment.

Articles