Лучший QA-тест для инженеров автоматизации тестирования: построение оценки

Что означает «лучший» для QA-тестов

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

Лучший QA-тест — это не самый сложный. Это тот, который показывает, сможет ли кандидат поддерживать набор тестов три года без выгорания.

Идеальная структура оценки

Часть 1: Проектирование тестовых случаев (письменное, 30–45 минут)

Это обязательно. Это первый фильтр.

Дайте кандидатам реалистичное описание функции — не «протестировать логин» (слишком расплывчато), не «написать 100 тестовых случаев» (слишком много). Что-то среднее: «Вот функция для массового импорта данных пользователей из CSV. Напишите 8–12 тестовых случаев, которые вы предложили бы своей команде».

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

• Охват: выявляют ли они граничные случаи (пустой файл, 100 тысяч строк, спецсимволы)?
• Ясность: может ли кто-нибудь другой выполнить эти тесты без обращения к ним?
• Суждение: расставляют ли они приоритеты критических случаев или относятся ко всем одинаково?
• Реалистичность: признают ли они ограничения (подготовка данных, окружение)?

Используйте рубрику: охват 25%, ясность 25%, суждение 25%, осуществимость 25%. Это не идеальная объективность, но это последовательность.

Время на оценку: 10–15 минут на кандидата. В масштабе вы можете формализовать подсчет баллов.

Часть 2: Код автоматизации (take-home, 2–3 часа)

Если они прошли часть 1, пошлите им take-home. «Вот тестовое приложение. Выберите 4–5 тестовых случаев, которые вы только что спроектировали, и автоматизируйте их. Используйте любой фреймворк, который вы знаете».

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

• Качество кода: читаемо, поддерживаемо, не чрезмерно остроумно?
• Мастерство фреймворка: корректный синтаксис, правильные утверждения, умные ожидания?
• Надежность: выживет ли этот тест при небольшом изменении UI, или он хрупкий?
• Архитектура: используют ли они page objects, подготовку данных, teardown?

Не оцениваете по скорости. Кандидат, который пишет 2 надежных теста за 2,5 часа, сильнее того, кто пишет 8 быстрых тестов в то же время.

Что игнорировать: выбрали ли они Selenium или Cypress, использовали ли они конкретную библиотеку. Это предпочтения. Качество теста — вот что имеет значение.

Время на оценку: 15–20 минут. Ищите: селекторы, которые не сломаются, ожидания, которые имеют смысл, утверждения, которые проверяют поведение (не просто состояние DOM), и код, который легко читается человеком.

Часть 3: Живое интервью (60 минут)

Здесь суждение сияет. Подготовьте 2–3 сценария:

Сценарий 1: «Ваш набор регрессионных тестов занимает 3 часа. Команда хочет сократить его до 1 часа, чтобы разблокировать более быстрые развертывания. Какой ваш план?»

Сценарий 2: «Критическая ошибка в production была пропущена вашим набором тестов. Это race condition, которая происходит 1 раз из 100. Пройдитесь через вашу методику расследования».

Сценарий 3: «Функция запускается через 2 недели. Тестирование не завершено. Развертывание без полного охвата подвергнет нас риску потери данных. Что вы предлагаете?»

Ни один из этих ответов не является правильным. Вы слушаете:

• Задают ли они уточняющие вопросы (размер команды, влияние на пользователя, бюджет)?
• Могут ли они сформулировать trade-offs без избегания?
• Думают ли они как инженеры (риск, ROI, поддержка) или просто как тестировщики (охват)?
• Честны ли они об ограничениях?

Время: 20 минут на вопросы, 10 минут на их рассуждения, 30 минут на follow-ups и их вопросы к вам.

Часть 4 (опционально): Упражнение на review кода (30–45 минут)

Если ваша QA роль включает проверку тестового кода, добавьте это.

Предоставьте набор тестов с 3–5 проблемами: хрупкий селектор, отсутствующая обработка ошибок, переопытый тест, race condition setup/teardown. Попросите их выявить проблемы и предложить исправления.

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

• Могут ли они читать и критиковать код?
• Понимают ли они режимы отказа?
• Практичны их предложения или теоретичны?

Это необходимо только если ваша команда действительно проверяет код тестов. Многие этого не делают.

Общее время инвестирования

• Часть 1 (письменное): 45 мин время кандидата, 10–15 мин оценка
• Часть 2 (take-home): 2–3 часа время кандидата, 15–20 мин оценка
• Часть 3 (живое интервью): 1 час время кандидата, 30 мин интервью, 10 мин заметки
• Часть 4 (опционально): 30–45 мин время кандидата, 10 мин оценка

Итого: 4–5 часов времени кандидата, 1,5–2 часа времени рекрутера/интервьюера на кандидата. Это приемлемо для старшего найма.

Screening перед этой оценкой

Не отправляйте take-home всем. Используйте часть 1 (письменное проектирование тестовых случаев) как screener.

Если они не могут спроектировать последовательный тестовый случай за 45 минут, они не напишут надежный код автоматизации. Сохраните 3-часовой take-home для кандидатов, прошедших письменный раунд.

Примерный процент прохождения: стремитесь к 40–60% письменных подачей на продвижение к take-home. Если это намного выше, ваша рубрика слишком мягкая. Если ниже, ваша спецификация может быть неясной.

Калибровка оценки

Перед наймом, откалибруйте вашу команду на том, что означает «хорошее».

Запустите оценку на 2–3 известных хороших нанятых из вашей команды. Как выглядят их тестовые случаи? Какое качество их кода? Используйте это как ваш эталонный стандарт.

Затем запустите 2–3 известных плохих нанятых (люди, которые не сработали). Что было слабым в их подачах? Это отрицательное пространство тоже имеет значение.

Вы не пытаетесь быть совершенно объективны. Вы пытаетесь быть последовательны.

Когда пропускать части

Наём для role ручного QA (исследовательское, не автоматизация): пропустите часть 2 и часть 4. Сосредоточьтесь на части 1 (мышление о тестировании) и части 3 (суждение).

Наём инженера среднего уровня с проверенным портфолио: вы можете пропустить часть 1 (проектирование тестов) и сразу перейти к части 2 (код) и части 3 (интервью). Но только если вы уже видели их реальный код.

Наём в масштабе, ранняя стадия: начните с части 1 + часть 3 (пропустите take-home). Это быстрее. Как только ваш процесс стабилизируется, добавьте часть 2 для финальных раундов.

Почему эта структура лучше альтернатив

Лучше, чем Leetcode-style проблемы: они проверяют скорость кодирования под давлением, не мышление о тестировании или архитектуру.

Лучше, чем только live coding интервью: вы не можете оценить способность кандидата проектировать тесты или поддерживать код в 60-минутной живой сессии.

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

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

Counter-consideration: может быть, вы нанимаете неправильно

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

Это справедливо, если ваши инженеры достаточно сильны. Но сильные инженеры, нанятые для «также тестирования», часто этого не делают. QA становится задачей, которую они ненавидят. Вы получаете необслуживаемые тесты и выгоревших инженеров.

Нанимайте людей, которые выбрали эту дисциплину. Оценка поможет вам их найти.