Экспресс-отбор для QA: как проверяют тестировщиков за 30 минут

Представьте, что вы откликаетесь на вакансию тестировщика и получаете тестовое задание, которое отнимает целые выходные – а потом узнаёте, что работу отдали кандидату с большим опытом. Именно так произошло с одним новичком QA: он потратил три дня, записал около ста баг-репортов для тестового проекта, но в итоге компания предпочла другого человека (источник software-testing.ru). Разочарованный кандидат поделился своей историей на форуме и задался вопросом – нормально ли требовать от соискателя столько бесплатной работы?

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

Такая ситуация – не редкость в IT. Споры вокруг тестовых заданий для QA-инженеров идут уже не первый год. Одни компании продолжают присылать объёмные задания, фактически вынуждая соискателей выполнять мини-проекты бесплатно. В то же время все больше работодателей переходят на экспресс-тесты: небольшие задания или вопросы, которые позволяют за короткое время понять навыки кандидата. Попробуем разобраться, почему в подборе QA все более популярны быстрые тестовые задания, чем они отличаются для ручного и автоматизированного тестирования, и как они помогают (или мешают) найти лучших специалистов.

Фильтр резюме: зачем нужны тестовые задания

При найме специалистов работодатели стремятся максимально эффективно отсеивать неподходящих кандидатов. Процесс найма – это воронка, где каждый этап отфильтровывает часть людей, экономя время и ресурсы команды (источник dou.ua). Если рассматривать гипотетическую ситуацию: на вакансию откликнулось 100 тестировщиков, и со всеми провести по два часовых интервью (техинтервью и встречу с руководителем), то суммарно команда потратит 400 часов. Причем после бесед может выясниться, что кто-то не владеет нужными технологиями, кто-то не умеет писать автотесты, кто-то не разделяет ценностей компании – но время уже упущено.

Тестовое задание в этой «воронке» служит одним из ранних фильтров. Его смысл – выявить неподходящих кандидатов быстрее и дешевле. Просмотр резюме занимает минуты, телефонный скрининг – десятки минут, проверка выполнения небольшого тестового задания – еще 10–20 минут. Именно в таком порядке компании и выстраивают этапы отбора – от менее затратных к более трудоёмким. Зачем тратить часы на интервью, если с помощью короткого теста можно сразу понять, способен ли человек справляться с базовыми задачами QA?

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

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

Конечно, одним фильтром дело не ограничивается. Компании зачастую оценивают и теоретические знания (например, задают вопросы по методологиям тестирования), и софт-скиллы на финальных этапах. Но именно практическое задание дает представление о том, как человек подходит к работе. И задача работодателя – сделать эту проверку максимально показательной, но при этом быстрой и комфортной для всех участников.

Три дня или 30 минут: зачем сокращают задания?

Вернемся к истории несчастного кандидата, отдавшего три дня на тестирование приложения. Почему сообщество QA восприняло это негативно? Дело не только в потраченном времени, но и в ощущении несправедливости.

В обсуждении того случая прозвучала шутка: «Ну что ж, вы поучаствовали в бесплатном бета-тестировании игры! Осталось добавить это в резюме». Горькая ирония: вместо оценки навыков соискателя компания фактически получила от него полноценную работу – и даже не предложила должность.

Такие практики вредят и кандидатам, и репутации работодателя. В индустрии все чаще звучит мысль, что требовать долгих неоплачиваемых усилий неэтично (источник nonprofitaf.com). Мало кто из соискателей имеет роскошь проводить дни над тестовым, особенно если параллельно они ищут работу и выполняют задания для нескольких компаний сразу. Самые ценные кандидаты, имеющие выбор, скорее откажутся от участия в таком марафоне, чем будут ночами дописывать отчёты. В итоге работодатель рискует потерять сильного специалиста на этапе отбора – просто потому, что перегнул палку с требованиями.

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

Неудивительно, что многие компании пересматривают свои требования. Например, ряд команд переносит тестовое прямо на само собеседование. Тот же совет давали QA-специалисты на форуме: дать задание очно на 20–30 минут. Похожим опытом делится и один из руководителей разработки: по его словам, их команда решила вовсе не высылать домашнее задание заранее, а предложить небольшую задачу непосредственно на интервью, выделив на неё 15 минут.

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

Конечно, 15–30 минут – это экстремально короткий формат. Чаще встречается компромисс: тестовое задание дают домой, но строго ограничивают его объем. Многие компании прямо пишут, что выполнение не должно занять более 4 часов.

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

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

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

Чем проверяют manual и automation QA

Тестовые задания для ручного тестировщика (manual QA) обычно отличаются от задач для инженера по автоматизации тестирования (QA automation). Это логично: роли требуют разных навыков, поэтому и мини-экзамен должен фокусироваться на нужных умениях.

Для manual QA главное – умение тщательно исследовать продукт, продумывать сценарии и находить дефекты в интерфейсах и логике. Классическое задание для ручного тестировщика – придумать тест-кейсы или чек-лист для базового функционала приложения. Например, соискателю могут показать упрощенный макет страницы интернет-магазина (скажем, корзины товаров) и попросить перечислить, что и как нужно проверить (источник habr.com).

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

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

Оптимальный ответ – набор дат до и после 18-летнего порога, включая крайние случаи (день в день 18 лет, на один день младше, на месяц старше и т.п.). Если претендент владеет техниками тест-дизайна (в данном случае анализ граничных значений), он без труда составит такой список. Это демонстрирует системное мышление: умение покрыть все критичные сценарии минимальным числом тестов.

Наконец, известный «креативный» экзамен для тестировщика – протестировать простой предмет. Например, кандидату предлагают: «Вот карандаш. Как бы вы его протестировали?» Смысл задачи – проверить навыки аналитического мышления и полноту подхода в отсутствии формальных требований. Опытные QA прежде всего уточнят требования: а что вообще считать нормой для карандаша, какие характеристики важны? Если соискатель сразу бросается перечислять проверки, не выяснив контекста, это считается ошибкой.

Но стоит ему задать вопрос «Какие требования к карандашу?», как интервьюеры уже довольно кивают – человек мыслит правильно. После этого кандидат, как правило, разбивает тестирование на этапы: исследовательский подход (понять, что карандаш должен уметь писать, стирать, быть удобным формы и т.д.), позитивные тесты (пишет ли на бумаге разных видов, чертит ли линии под углом и т.п.), негативные тесты (что будет, если писать по мокрой бумаге, по дереву, по морозу?). Подобный экзамен скорее проверяет общий склад ума, чем знания конкретных инструментов, но в найме джуниор-QA он довольно распространен. Главное – смотреть, как кандидат рассуждает, насколько он внимателен и дотошен в деталях.

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

Например, дать описание пользовательского кейса на сайте и требование автоматизировать проверку этого сценария. Так поступает руководитель QA в одной из компаний: кандидату дают user story из реального продукта и просят реализовать тест – найти нужные элементы на странице, выполнить действия, проверить ожидаемый результат. В итоге видно, как человек пишет код UI-теста, насколько хорошо знает инструменты вроде Selenium (умеет ли находить элементы по надежным локаторам и т.д.), может ли связывать шаги теста с тест-кейсами.

Важно, что подобное задание не превращается в мини-проект. По словам экспертов, тестовое для автоматизаторов не должно быть слишком большим или сложным, его выполнение – не более 4 часов работы. Проверяющие обычно заранее продумывают критерии оценки: выполнил ли кандидат все требования, написал ли действительно автотест, а не набор скриптов. Последний пункт интересен: некоторые неопытные QA могут попытаться использовать record-playback инструменты (рекордеры, записывающие действия в браузере) вместо того, чтобы самостоятельно программировать тесты.

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

Бывают и курьезы: небольшая доля кандидатов пытается вовсе не своими силами выполнить тестовое задание – например, берут готовый чужой код или просят помощи друзей. Но опытный интервьюер вычислит это за пару уточняющих вопросов на очном собеседовании. Поэтому обмануть систему вряд ли удастся. Гораздо важнее для автоматизатора – показать свой стиль работы: структуру кода, умение обрабатывать ошибки и исключения, продумывать edge cases (крайне редкие случаи).

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

Иногда в заданиях по автоматизации используют и ревью чужого кода. Кандидату дают небольшой фрагмент программы (например, класс и интерфейс к нему) – с намеренно допущенными изъянами – и просят за ограниченное время найти ошибки или слабые места. Этот метод близок к реальной задаче code review и позволяет проверить сразу две вещи: знание принципов написания качественного кода и внимательность при анализе чужой работы.

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

Стоит ли игра свеч?

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

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

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

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

А для этого достаточно одной небольшой, но меткой задачи. Главное – правильно её подобрать и оценить результат по существу. Тогда тестовое задание действительно сыграет роль полезного фильтра, а не превратится в источник разочарования для всех участников процесса.