Comments 21
Скажите, пожалуйста, насколько сейчас реально найти работу QA без опыта работы?
Пробовать стажировки, куда берут. В свое время получилось через яндекс попасть в тестирование. Может быть есть в регионе твоем, мелкие аутсорс компании.
У меня есть пара знакомых, которые могут посмотреть резюме, есть кто может подтянуть по теории, подсказать как и где откликаться. Но сейчас без опыта стало сложнее это факт.
На технических собеседованиях мне не задавали вопросов по типу «Какая цель тестирования?», «Дайте определение такому-то виду тестирования».
Разве это технические вопросы? Это вопросы теории, к которой так же может пойти расхождение в понимание и т.д. К сожалению на рынке так не научились собеседовать людей с опытом. Ты можешь ответить на часть теории, которую помнишь, но часть интервьюеров строят из себя экзаменаторов и пытаются выбить ответ по методички
У тебя есть стенд, на котором пройден регресс. Пришёл проджект-менеджер и сказал, что в завтрашний релиз надо включить ещё одну фичу. Что будешь делать?
Пришла таска, доки нет.
Можно ли релизить фичу с багами?
Есть короткое описание фичи. С чего начнёшь тестировать, если времени мало?
Тоже абстрактные вопросы. Нет понимание, чего хотя услышать, что ты будешь подлизывать менеджеру или держать здравую позицию на такие выходки и готов блокировать релиз.
. Обязательное требование, которое часто встречается, — опыт от года в написании автотестов на определённом языке программирования (далее — ЯП).
Тоже убивает. Во первых такой опыт за частую сложно взять, бывают компании, где автоматизаторы отдельные люди. И в силу причин некоторых, не всегда до обычных qa может дойти навык автоматизации и что им помогут обучить. Да и возникает вопрос времени, так как есть куча новых задач, которые приоритетный или просто на не большой кол-ве держится проект.
Потом возникает ситуация странная, если ты даже связывался с автоматизацией, то ты ограничен стеком и выбором вакансий. При этом ты не можешь например легко перейти даже внутри фронтового тестирования на другие проекты, при этом не говоря про смену более фронт тестирования на бэк.
Ощущение, что рынок идет в какое то не понятную ситуацию и сам ограничивает себе классный людей. Зацикливаясь на том, что все qa должны писать код для автоматизации.
Тоже абстрактные вопросы. Нет понимание, чего хотя услышать, что ты будешь подлизывать менеджеру или держать здравую позицию на такие выходки и готов блокировать релиз.
Оказалось, что им нужно было быстро выпускать фичи, т.к. сроки поджимали. Требовалось закрывать глаза на баги некритичные, и выпускать в релиз, что скажут. Быстро тестировать. Это в конце они мне рассказали. Так что с одним из вариантов ты угадал:
Самый первый комментарий как раз о том же, как найти работу без опыта. Читал статью пару лет назад, от имени HR. Жаловались, что компании хотят найти сотрудников с опытом, но при этом не готовы сами обучать сотрудников без опыта. Очевидно, у компаний свои мотивы. Допускаю, что мне на глаза попадались вакансии, где требовался ЯП, т.к. у меня есть опыт использования, а вакансии без требования ЯП я мог игнорировать. Тут в целом о рынке судить будет сложно, опираясь только на мой субъективный 2-х недельный опыт в поиске.
Ну такое может быть, но тогда ответственность за релиз берет явно не тестирование и об этом договариваются. Если нарушаются нормы релизного выпуска.
При это где гарантии, что не возникнет крит в этой ситуации, ну разумней решать по результатам прогона.
Без понимания, что продукт, в какой стадии и тд, сложно отвечать на этот вопрос.
Даже, смотря что они считают не критовыми багами
Я так и ответил, что ответственность тогда на себя должен брать бизнес, баги все равно будут висеть в бэклоге. Там тестирования по сути и не было, первый тестер на проект, собеседовал нанятый на парт тайм тим лид, его задачей было найти QA.
Не всегда бывает так. Хотя и довольно часто. По-хорошему, решение выпускать в релиз или нет - принимает как раз Продукт-Менеджер. Задача тестировщика позволить ему сделать информированое решение. Т.е. предоставить максимально подробный и правдивый отчёт о текущем состоянии продукта/релиза. А там уже ответственность Менеджера выпускать это или нет. Еще ему можно помочь адекватным тестпланом, в котором должно быть прописано - допустимый уровень дефектов каждого приоритета. Если допустимый уровень zero bugs, тогда можно и блокировать. Но таких продуктов не так уж и много. Все равно какой-то уровень minor/cosmetic допустим.
Хожу на собеседования как Senior SDET (или Lead) уже последние лет 5, основной стэк у меня Python. Прошел собесов 30 примерно и за это время собесы стали лучше. Все меньше стали лайв кодить, все меньше стало тупых вопросов и бесполезных тестирований, также этапов становится поменьше. К тому же стэк, если рассматривать один язык, для тестирования один и тот же, и в каждом языке свой, как и инфраструктура в целом.
Самое плохое, что я встречаю, это когда происходит собеседование первого QA и этим занимается далекий от этого человека (зачастую CTO или напыщенный главный разработчик), в этом случае они ждут совпадение ответа с тем, как считают они, либо ждут такую глубину, как будто собеседуют на Senior Architect Developer. (как пример, спрашивали о возможных уязвимостях в docker контейнере и теоретических возможностях его взлома, при этом в компании докер использовался как и у всех, обычной запускалкой)
P.S. если вы идете собеседоваться по вашему основному языку и вы это заваливаете, то вам точно стоит не подготовиться, а подучить язык.
зачем кубер докер cicd, а девопсы на что?
Я тоже удивился, для чего?.. Смог ответить только на часть вопросов, и только потому что ранее брал это себе как точку роста и самостоятельно изучал. Больше удивили вопросы про ci/cd, ведь в работе все ограничивается тем, что ты выбираешь параметры и условную кнопку "Пуск" нажимаешь.
Не всегда у тебя будет выделенный девопс на проекте. А иногда у меня были такие девопсы, что это превращались в боль. Приходилось им писать пошаговую инструкцию, что нужно сделать. Доступов команде не давали из-за безопасности, а девопсы с доступами просто не владели нужным стеком, владели другим. Но проект стартануть нужно было быстро, а размер проекта порядка 200 человек.
Проще самому было сделать, но всё упиралось в доступы.
Привет автор. Учусь на тестировщика. Ты как прошедший уже некоторый путь на что посоветуешь делать упор?
Привет!
Самые стандартные темы: клиент-серверная архитектура (запросы поотправлять и разобраться как это все работает), чаще всего SQL, микросервисная архитектура, и + чем она отличается от монолитной, теория по тестирования, если опыта нет - будут ее спрашивать. Это первое что в голову пришло, а вообще открываешь вакансии, смотришь требования и по ним примерно учишься
О чём чаще всего спрашивают тестировщиков на технических собеседованиях
Удивительно насколько мой опыт поиска работы разнится в плане вопросов на собеседовании. У меня не было ни одного глубокого вопроса про Docker, Linux, устройство CI/CD. Если и были по ним вопросы, то формата с чем работал и что делал. Рассказываешь про свой опыт, подкрепляешь свой ответ дополнительным примером того, как это было релевантно в рамках своей позиции, после этого не требовались дополнительные знания.
А вот про клиент-серверное взаимодействие спрашивали очень много. Я бы сказал, что надо делать больше упор на него. Причем надо не заучить базовые вещи, а больше порыться в структуре запросов, ответах, в целом понимать как и что происходит. А если есть в позиции мобилки, прочитать про них все, включая структуру APK или IPA.
Все остальное в статье, включая "Чем отличаются собеседования в QA три года назад и сейчас" звучит очень похоже. Кроме того, сложилось ощущение, что стало больше технически слабых интервьюеров с небольшим опытом, которые не умеют рассуждать, критически мыслить и не могут принять ответ за рамками какой-то бумажки, где у них есть ответы. Я так задавал пару вопросов на уточнение и понимаю, что люди хлопают глазами и не могут ответить на вопрос и плывут.
Честно, я тоже ожидал более сложных вопросов по API, и готовился. И неожиданностью было встретиться то, о чем писал. Почему у нас такие разные впечатления были, может быть дело в стеке? Хотя, я в резюме указывал, что работал с докером и линуксом, могло же повлиять, как вы думаете?
Да много факторов может быть. Я на позицию Senior QA шел, может старались больше про опыт спрашивать и меньше про знания. Может и тэх стек другой был. Линукс вообще спрашивали только в одной компании, и то поверхностно.
А вообще в целом достаточно рандомно все, сложно подготовиться ко всем вопросам) Пишут один тех стэк в позиции, спрашивают про другой. Часто еще и ищут на позицию в другую команду, не на ту, что откликался, с другим набором требований, просто потому что что-то там передумали внутри команды. Я так уже с тремя менеджерами перезнакомился, потому что они не знали, куда меня пристроить)
клиент-серверное взаимодействие спрашивали очень много
Странный вопрос если не один проект был.
Кроме того, сложилось ощущение, что стало больше технически слабых интервьюеров с небольшим опытом, которые не умеют рассуждать, критически мыслить и не могут принять ответ за рамками какой-то бумажки, где у них есть ответы
А обычно так и делают. Пишут вопросы и ответы. Я еще видел в начале своей карьеры, такие листы в компании
Используете ли Вы в своей работе то, что Вас спрашивали на собеседовании при приеме на эту должность?
Как я проходил собеседования на QA-инженера в разных компаниях и что на них обычно спрашивали