Один тестировщик может протестировать что угодно, кроме самого себя. А два, как известно, могут протестировать вообще всё. В этой статье мы расскажем, как на самом деле обстоит процесс подбора тестировщиков в hh.ru.
Существует несколько этапов отбора специалистов и два больших фильтра в лице HR и Технического департамента:
Отбор резюме HR-специалистом
Отбор резюме тестировщиком
Опросник
Техническое собеседование
Тестовое задание и его проверка
Финал – знакомство с одной или с несколькими командами
Для полного счастья не хватает еще несколько кругов, не так ли? Просто представим, что они есть. Ниже мы подробнее разберем каждый из этапов и дадим пару советов, как проскочить их наиболее эффективным способом.
Отбор резюме рекрутером
Тут всё понятно. Рекрутер скринит известные и не очень ресурсы на предмет релевантных резюме, после чего несет лучшие на суд тестировщикам.
Пример резюме, которое нас заинтересует
Опыт работы:
Работа по методологии от Java: scrum/kanban
Принятие участия на самых ранних этапах разработки: от идеи до релиза фичи
Коммуникация с дизайнерами, заказчиками
Оценка возможных рисков
Работа с багтрекингом Jira/Confluence
Ручное тестирование frontend и backend
Проведение функционального, регрессионного, кроссбраузерного тестирования
Чтение логов – Linux, Kibana
Поддержка и написание новых тестов (Maven, TestNg, Selenium WebDriver, Java)
Использование SQL на уровне простых запросов
Работа с NoSQL субд (у нас есть Cassandra, желательно общее понимание)
Знание:
Основных понятий клиент-серверной архитектуры
Протокола http и его расширения https
Базовых команд Linux
SQL-синтаксиса
Базовые знания Java — Collection Framework, TestNg/Junit
Ключевые навыки:
Devtools – очень желательно. Достаточно редко попадаются соискатели-тестировщики, которые не работали с Devtools
Postman или аналоги. Должно быть представление, как работает инструмент
Любой из снифферов трафика
Docker
Что может насторожить
Здесь мы выносим свой вердикт и оставляем комментарии к резюме – что нам нравится, а что настораживает. Вот что может нас насторожить:
Желаемая должность
QA Automation engineer – у нас больше ручного тестирования и 20-30% автоматизации, человеку с такой должностью может быть скучно. В этом случае рекрутер связывается с кандидатами, чтобы уточнить, подходит ли соискателю такое процентное соотношение или нет. В 50% случаях кандидатам подходит такой процент автоматизации. Плюс у нас в компании есть все возможности вырасти в автоматизатора и разработчика.
QA Lead/Head of QA – поскольку мы ищем специалиста на позицию тестировщика, скорее всего кандидат с опытом руководства вряд ли захочет подобного "даунгрейда". Но всегда можно уточнить, ведь есть миллион случаев, когда специалисты "устают" от руководства и уходят обратно в инженеры.
Тестировщик (manual only) – если соискатель хочет работать ручным тестировщиком, мы уточняем этот момент. Бывают случаи, когда люди не хотят развиваться в автоматизации, а это один из этапов прохождения испытательного срока – написать автотест
Опыт работы
Руководство – в опыте указано руководство командой тестировщиков. Например, у соискателя в подчинении находились пять тестировщиков, он распределял задачи и ресурсы. Такие моменты уточняет HR, потому что есть люди, которым не понравилось лидство, и он захотел вернуться в ряды тестировщиков
Только автоматизация – разработка моков, поднятие автотестов с нуля. Таким специалистам, скорее всего, будет скучновато работать на 70% ручного тестирования
Нет опыта Web-тестирования – таких кандидатов мы не рассматриваем совсем.
Указано много видов тестирования в опыте работы, и ничего не написано про инструменты и технологии, которые использовались. С таким резюме шансы дойти до опросника значительно снижаются.
Опросник
После того, как мы просмотрели резюме и выбрали подходящие, отправляем их в опросник. Зачем?
Отсеиваем незаинтересованных кандидатов – такие либо вообще не присылают опросник, либо присылают неразвернутые ответы (да/нет/пч0лы)
Смотрим, рассуждает ли тестировщик в ответах или пользуется лишь заученными терминами
Проверяем «адекватность»: нет ли скрытой агрессии, например
Однако сейчас мы пытаемся ввести практику отказа от опросника, поскольку из-за него у нас нет-нет да отваливаются тестировщики с очень хорошими скиллами и мощными резюме.
Техническое собеседование
После опросника следует техническое собеседование. Успешный собес на практике всегда опирается на два простых правила:
Не более 4 человек от компании на собеседовании: один ведущий, двое помогают ведущему, также может быть один слушатель, который хочет прокачать навыки для проведения собеседований
Ведущий управляет собеседованием по определенному плану и выстраивает диалог
План собеседования:
Представляем коллег
Рассказываем про позицию (роль тестировщика в компании и команде, его обязанности)
Говорим про команды, в которые идет поиск
Предлагаем кандидату задать нам вопросы
Задаем собственные: про опыт, технические моменты и всё в таком духе
Ждем дополнительных вопросов от кандидата, если они есть
Завершаем собеседование
На что обращаем внимание:
Как складывается общение – как отвечает и подает себя соискатель
Готов ли работать без документации – в Техдепе ее мало, в основном – исследовательское тестирование. Это важный пункт, нужно уточнять, будет ли кандидату комфортно работать в таких условиях.
Как отстаивает свои позиции – разработчик закрыл задачу и говорит: «Это не баг, а фича», – вопрос заключается в том, как поступит кандидат
Проявление инициативы – здесь можно уточнить причину ухода соискателя с прошлой работы. Зачастую кандидаты отвечали, что не было развития и автотестов. И тут можно задать вопрос: что сделал кандидат для внедрения автотестов или улучшения качества работы сервиса
Опыт тестирования веба – знание соискателя об устройстве веба
Последний опыт работы – кандидат может рассказать о процессе, проекте, релизах или устройстве тестовых стендов
Что-то пошло не так
Иногда что-то идет не так, и надо плавно завершать собеседование. Вот распространенные кейсы:
Технический бэкграунд слабый, но по общению всё хорошо. У кандидата хорошие мотивация и обучаемость. Но сейчас он еще не готов: слишком «зеленый». В таком случае проверяем софт-скиллы и плавно завершаем собеседование. Обычно в Talantix мы пишем, что готовы рассмотреть такого человека через полгода-год.
С софт-скиллами все сложнее. Бывает довольно сложно определить, сможет ли специалист работать с нашими проектами. Например, иногда из-за специфики работы с госзаказами у людей складывается определенный тип общения. С такими кандидатами бывает тяжело, но через год они, как правило уже готовы к сотрудничеству и дальнейшей работе.
На хамство/агрессию не стоит реагировать остро. Мы плавно завершаем собеседование без каких-либо ответных реакций. Делаем отметку в Talantix, что этот человек совсем конфликтный и общаться мы с ним больше не будем. Главное – не идти эскалацию конфликта.
Больше всего внимания мы уделяем софт-скиллам. У нас нет тестовой документации, поскольку для поддержания ее в актуальном состоянии потребуется еще один отдел. Отдел поддержания документации в актуальном состоянии, you know.
Поэтому важны софт-скиллы тестировщика, так как придется много общаться с заказчиками и другими командами разработки для уточнения требований. Обычно мы спрашиваем, как у кандидата происходило взаимодействие с командой и заказчиками. Какие действия он предпринимал для решения тех или иных проблем. Чтобы он делал в случаe разногласия с разработчиком, на вопрос “баг это или фича”.
Тестовое задание
Если всё прошло как надо, после технического собеседования мы высылаем кандидатам тестовое, которое включает в себя:
Написание тест-кейсов на страницу hh: создание резюме, поиска
Оценку времени тестирования
Найденные баги, которые кандидат заметил, пока составлял тест-кейсы
Буквально неделю-две назад мы начали пропускать этап тестового задания. И заметили тенденцию – когда выдавали тестовое задание хорошему кандидату с оффером из другой компании, он моментально отваливался. Зачем ему делать еще какие-то задания, когда у него уже есть прекрасный оффер?
Поэтому иногда этот шаг может быть включен в этап технического собеседования.
Финалочка
И вот он наш герой: прошел огонь, воду и тест-кейсы. Дошел до финала. Здесь кандидата ожидает знакомство с командой. Здесь уже ребята из команд сами подбирают для себя людей под свои интересы и задачи. Чаще всего используется такой алгоритм:
Анализируем личные качества кандидата
Смотрим, насколько подходит команде по общению/интересам
Кандидат интересуется своей будущей командой и оценивает, насколько она ему подходит