Как оценивать QA-инженеров: построение структурированного процесса найма

Почему наём QA сломан

Большинство компаний оценивают QA-инженеров как программистов с значком QA. Они задают алгоритмические задачи, проводят кодовые тесты и измеряют скорость синтаксиса. Но QA-инженерия — это не программирование с другими инструментами. Это другая дисциплина: речь идёт о риске, компромиссах и суждениях в условиях ограничений.

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

Три уровня QA-оценки

Уровень 1: дизайн тестовых случаев (письменный, 45 минут)

Дайте кандидатам реальную спецификацию функции и попросите написать 12–15 тестовых случаев, которые они бы предложили команде. Без кода. Просто случаи.

Что вы оцениваете:

• Покрытие: определяют ли они happy path, случаи ошибок, граничные случаи и переходы состояний?
• Ясность: может ли кто-то ещё прочитать и выполнить тестовый случай без вопросов?
• Приоритизация: отмечают ли они критичное vs. nice-to-have, или рассматривают все случаи как одинаково важные?
• Контекстное сознание: задают ли они вопросы об окружении (production-данные, поддержка браузеров, baseline производительности)?

Сильная работа включает: предусловия, шаги теста, ожидаемые результаты и почему каждый случай важен. Слабая работа либо слишком детальна (50 однострочных случаев), либо слишком расплывчата ("протестируйте логин").

Это основание. Если они не могут дизайнить тестовый случай, фреймворки автоматизации не имеют значения.

Уровень 2: портфель автоматизации (take-home, 2–3 часа)

Отправьте им небольшой open-source проект или песочницу. Попросите написать 4–6 автоматизированных тестовых случаев, используя их фреймворк по выбору.

Что вы оцениваете:

• Беглость фреймворка: могут ли они написать валидный, запускаемый код на Selenium, Cypress, Playwright или том, что вы используете?
• Структура тестов: независимы ли тесты, читаемы и поддерживаемы? Или они связанные, hardcoded и хрупкие?
• Надёжность: используют ли они ожидания, обработку ошибок и селекторы, которые не сломаются при мелких изменениях UI?
• Документация: могут ли они объяснить, почему они выбрали свой подход?

Честно говоря: техническое качество автоматизации менее важно, чем мышление за ней. Кандидат, который пишет 3 solid тестовых случая с хорошими assertions, сильнее, чем кто-то, кто пишет 8 хрупких, которые сломаются при каждом развёртывании.

Ключевой вопрос на follow-up: "Если этот тест сломается завтра, как вы его отладите?" Их ответ показывает, понимают ли они код или просто скопировали его.

Уровень 3: процесс и суждение (live интервью, 60 минут)

Объедините это с live раундом. Представьте реальный сценарий: "У нас есть 2-часовой тестовый набор. Мы хотим сократить его до 30 минут. Что вы делаете?" или "Функция выходит через 2 недели. Тестирование не готово. Что вы предпринимаете?"

Это то место, где циклы интервью senior-инженеров применяются к QA: вы не тестируете знание, вы тестируете суждение.

Что вы измеряете:

• Думают ли они стратегически (риск, ROI, область) или тактически (скорость, покрытие)?
• Могут ли они возражать нереальным сроком без конфликта?
• Понимают ли они бизнес-контекст (стартап vs. regulated, user-facing vs. internal)?
• Могут ли они артикулировать компромиссы без шатания?

Задавайте follow-ups. "Расскажите о времени, когда вы должны были выбрать между тестированием и shipping. Что было вашим решением?" Слушайте честность и рассуждение, не героику.

Опциональный уровень: оценка качества кода

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

Это фильтрует людей, которые могут поддерживать код, а не просто писать его.

Как оценивать в масштабе

Для массового найма используйте платформы оценки, которые могут:

• Оценивать дизайн тестовых случаев на покрытие, ясность и полноту (не идеально — просто хороший сигнал)
• Запускать представленный код автоматизации в песочнице и сообщать о pass/fail и метриках качества кода
• Записывать live coding интервью для async-обзора, если live раунды слишком дорогие

Цель — не идеальная объективность. Это консистентность и скорость. Rubric, который измеряет покрытие, ясность и артикуляцию компромиссов, побеждает произвольное gut feeling каждый раз.

Red flags во время оценки

• Over-automation: "Мы должны автоматизировать всё, особенно UI." — Предполагает, что они не понимают ROI или стоимость поддержки.
• Under-automation: "Ручное тестирование более надёжно." — Может не иметь практического опыта с modern фреймворками.
• Framework absolutism: "Единственный правильный инструмент — [Tool]." — Обычно означает ограниченный опыт или упорство.
• Missing context: Тестовые случаи, которые не учитывают setup данных, окружение или зависимости. — Предполагает, что они тестировали только простые flows.
• No prioritization: Все тесты взвешены поровну, нет упоминания риска или критичности. — Red flag для суждения.

Ни один из них не является disqualifying отдельно. Но если вы видите два или три вместе, наём, вероятно, нуждается в инвестировании на ramp-up.

Когда нанимать test automation инженеров vs. manual QA

Этот подход оценки работает для обоих, но вес смещается:

Test automation инженеры (80% код, 20% стратегия): тяжелее на беглость фреймворка и структуру кода, легче на дизайн тестовых случаев.

Manual QA / exploratory testers (20% код, 80% стратегия): тяжелее на дизайн тестовых случаев, думание о граничных случаях и суждение. Кодовая беглость менее важна.

Процессное интервью применяется к обоим. Компромисс-мышление — это то, что отделяет хорошие наёмы от burnout-наёмов в этой дисциплине.

Построение согласия для QA оценки

Если ваша инженерная команда никогда не проводила структурированное QA интервью, они возразят: "Мы должны просто нанять кого-то, кто хорош в поиске bugs." Но "поиск bugs" — это результат, не навык. Вы не можете измерить результат, пока они не наняты.

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

Начните с уровня 1 (дизайн тестовых случаев). Это самое быстрое для оценки и наиболее универсально раскрывающее. Добавляйте уровни по мере уточнения вашего процесса.