Автор: Дмитрий Волошин, QA Engineer, DataArt

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

Все началось с того, что мы несколько недель не могли закрыть ни одну позицию Trainee/Junior QA. Рекрутеры разводили руками: на очередную вакансию только за семь первых дней пришло несколько сотен откликов. Но даже кандидаты с хорошо расписанными резюме, подтвердившие знание теории, не справлялись с элементарными задачами по техникам тестирования или не находили явные баги при прохождении практической части собеседования.

Глубинная причина была ясна: как раз набирала обороты легенда, будто тестирование — легкий способ попасть в IT. Ее охотно укрепляли многочисленные новообразованные курсы QA, но уровень подготовки их выпускников вызывал вопросы. 

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

Тем не менее, предлагая проделать какую-то работу еще до первой встречи, всегда следует учитывать следующие факторы:

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

Поэтому мы решили отправлять его только соискателям с минимальным опытом или вовсе без него. 

Само задание должно было соответствовать следующим критериям: 

1. Иметь структуру, которая позволит его быстро проверить.
2. Быть простым для выполнения.
3. Обладать глубиной, за счет которой кандидат может продемонстрировать уровень знаний, превышающий необходимый минимум.
4. Не ограничиваться стандартными теоретическими задачами.
5. Обеспечивать возможность быстро дать обратную связь кандидату, который вложил свое время в его выполнение.

ПРОРАБОТКА РЕШЕНИЯ

Сформулировав критерии, мы начали проработку структуры тестового задания. За основу взяли регистрационную форму известной платежной системы, куда добавили баги, сгруппированные по объекту тестирования. А именно:

1. ФУНКЦИОНАЛЬНЫЕ: базовые ошибки валидации полей.
2. UI/UX: моменты, нарушающие базовые паттерны, и кнопки, неудобные для клика мыши.
3. БЕЗОПАСНОСТИ: всевозможные SQL-инъекции. Если сильно постараться, можно было даже попасть в БД. 
4. СОВМЕСТИМОСТИ: в разных браузерах отображение элементов было модифицировано.
5. ЛОКАЛИЗАЦИИ: задание предполагало вдумчивое чтение английского текста.

Поскольку мы ждали от кандидатов и общего понимания системы, добавили некоторые логические противоречия. К примеру, в задании имелась кнопка, которая не выполняла никаких действий, а на введенный кандидатом электронный адрес приходило неструктурированное письмо с адреса thisisdefinitelyspam@mail.com.

Основная идея фильтрации заключалась в том, чтобы сразу выявить тех, кто обращает внимание только на функциональные проблемы и не видит остальных.

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

1. В коде находилось изображение божества пастафарианства — Летающего Макаронного Монстра.
2. Можно было раскомментировать кнопку “Destroy This World”, при нажатии на которую появлялось изображение пришельца с бокалом пива и надпись “I’m here just for a beer”.
3. В коде футера страницы был оставлен комментарий несуществующего разработчика. С ним мы немного перестарались — текст был написан в лучших традициях мемов Reddit. К счастью, вовремя вмешался HR-департамент: мы послушали лекцию о двусмысленных шутках и реакции на них, после чего комментарий оперативно отредактировали.

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

От кандидата не требовалось выполнить задание на 100 %, достаточно было обнаружить хотя бы половину ошибок. Сама структура позволяла сделать предварительную оценку, лишь посмотрев на список баг-репортов и их оформление.

РЕЗУЛЬТАТ

Идея отсеивать тех, кто обращает внимание лишь на функциональные проблемы, сработала. Поток кандидатов, которых мы приглашали, сократился в 4–5 раз.

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

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

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

Некоторые соискатели сразу возвращались к нам с вопросом «что и куда мы регистрируем?», что, несомненно, говорило в их пользу. Сначала я придумывал скучные ответы, пока однажды не предложил рекрутеру написать: «Мы регистрируем сову для поездки в Хогвартс». Отчеты тех, кто знал, что тестирует регистрацию совы, стало значительно интересней проверять.

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

ЗАКЛЮЧЕНИЕ

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

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

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