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

Про команду QA

Сейчас в отделе QA у нас работает 22 человека, в ближайшем будущем планируем расшириться до 27. 

Территориально наши сотрудники обеспечения качества разбросаны по разным регионам: от Москвы и Питера до Екатеринбурга и Новосибирска, есть несколько человек из Тверской и Московской областей.

В QA у нас нет разделения на фронтенд и бэкенд — все наши специалисты выполняют ручное фулстек-тестирование. Инженеры работают по трем продуктовым направлениям: мобильное приложение, веб и финансовый маркетплейс.

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

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

Найм в доковидные времена

Раньше весь процесс найма у нас проходил в оффлайне: мы приглашали кандидатов в офис и проводили интервью — сначала по общим вопросам и предыдущему опыту, по софт-скиллам, а потом по техническим вопросам. 

Например, на первой встрече обычно обсуждали такие вопросы:

• предыдущий опыт кандидата, специализация (веб, мобайл, автоматизация, нагрузочное тестирование);

• в какой команде кандидат работал, сколько было человек, какие роли выполнял.

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

На техническом собеседовании мы проверяли хард-скиллы, например:

• работа с Git;

• работа с логами;

• знание TeamCity;

• понимание DOM;

• ориентирование в devtools (например, спрашивали, где посмотреть коды ответа групп 3**, 4**, 5**, 2**);

• работа с багтрекерами;

• ведение тест-кейсов;

• понимание процессов клиент-сервер (что происходит и где что обрабатывается при вводе запроса);

• работа с БД (SQL-запросы).

Найм в онлайне

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

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

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

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

Также мы разработали систему грейдов от джуниора до QA-лида, так называемую матрицу собеседований. В зависимости от уровня кандидата, мы задавали вопросы из соответствующей колонки (зелёная – для джунов, жёлтая – для мидлов, красная – для сениоров). Справа мы прикрутили чекбоксы для оценки того или иного скилла (да/нет).

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

Помимо этого, мы разбавили теоретические вопросы тестовыми задачами (до 5-6 заданий за собеседование). Это могли быть задачи по разрешению разных ситуаций, обнаружение багов, анализ возникшей ошибки, работа с БД и так далее.

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

Сейчас у нас накопилось уже более 70 анкет от разных кандидатов. Так что, если кто-то захочет получить обратную связь или приходит к нам повторно, мы всегда можем поднять анкету и вспомнить, как проходило собеседование. У нас есть кейсы когда кандидат приходил к нам, не проходил собеседование, получал обратную связь, а через полгода мы повторно встречались и выставляли оффер.

Про онбординг

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

Чтобы решить эту проблему, мы составили план адаптации новых сотрудников. Он представлял из себя понедельный список того, что нужно изучить, попробовать, с кем познакомиться, чтобы плавно погрузиться в работу компании. Этот план был рассчитан примерно на 2,5 месяца. Каждую неделю я проводил встречу с новичком и рассказывал про какую-то очередную команду и/или инструмент.

Также я ставил каждому новоприбывшему цели на испытательный срок. Например, такие: выстроить процесс тестирования в команде, сделать описание продукта, освоить работу с тестовым окружением, и т. д. — в зависимости от квалификации сотрудника и команды.

Потом этот процесс стал неудобным, так как количество новичков возросло, и мне стало сложно всё успевать. Тогда я решил немного поменять подход и перенёс онбординг в Confluence, где собрал все материалы на одной Welcome-странице, чтобы сотрудники могли самостоятельно с ними ознакомиться.

Затем я решил подключить к адаптации новичков их коллег по команде, чтобы они помогали им освоиться и формировали список задач на испытательный срок. Для этого я отсылал продактам или техлидам анкету с вопросами: какие у них есть ожидания от сотрудника, что он должен сделать за испытательный срок. Затем всё это компоновалось в единый список задач в Jira. Но такой подход не сработал, потому что задачи, которые поступали от продактов или техлидов, часто слабо коррелировали с обязанностями тестировщика (особенно на первоначальном этапе). 

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

Если ещё на этапе собеседования я вижу, что кандидат нам в целом подходит, но есть какие-то пробелы в знаниях, то я конвертирую эти пробелы в цель на испытательный срок. Допустим, если новичок плохо разбирается в SQL или не понимает философию CI/CD, то я ставлю ему задачу подтянуть эти навыки в течение испытательного срока.

Сейчас мы придерживаемся этой модели онбординга и время от времени вносим какие-то доработки и улучшения.

Что в итоге?

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

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

Если у вас возникли какие-то комментарии или вопросы, с удовольствием отвечу!