Примеры вопросов QA-тестировщика: что спрашивать на технических интервью

Почему стандартные вопросы QA не работают при найме

Большинство вопросов на интервью QA попадают в две ловушки: они либо настолько общие ("В чём разница между тестированием и QA?"), что любой, кто прошёл сертификационный экзамен, может на них ответить, либо настолько специфичны для вашего стека технологий, что проверяют знание фреймворка, а не умение думать. Кандидаты, которые запоминают терминологию тестирования, звучат компетентно. А те, кто действительно находит проблемы в ПО и улучшает процессы, остаются незамеченными.

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

Примерный вопрос #1: Сценарий с отчётом об ошибке

"Вы тестируете процесс оформления покупки в интернет-магазине. Платёжный шлюз иногда принимает дублирующиеся транзакции — тот же ID заказа, та же сумма, в течение 5 секунд. Это происходит примерно в одном случае из 50. Расскажите, как вы будете это исследовать и документировать."

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

• Задают ли они уточняющие вопросы (какой способ оплаты? какой браузер? условия сети)?
• Различают ли они воспроизведение ошибки, её корневую причину и область охвата (это в их коде или в коде платёжного шлюза)?
• Могут ли они сформулировать тестовый случай, который её поймает снова?
• Будут ли они эскалировать проблему или попытаются воспроизвести её сами в первую очередь?

Это показывает, думают ли они как инженеры (корневая причина, область охвата, профилактика) или просто как репортёры (симптом, скриншот, тикет).

Примерный вопрос #2: Компромисс при автоматизации

"У вас есть набор тестов, который выполняется 2 часа полностью. Ваша команда запускает его раз в день. Коллега предлагает автоматизировать UI-поток для загрузки изображений — примерно 40 строк Selenium и 15 минут техническом обслуживания в квартал. Вы это сделаете? Расскажите о вашей логике."

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

• Думают ли они о ROI (стоимость автоматизации против стоимости повторного ручного тестирования)?
• Знают ли они, когда автоматизация — это затраты, а не эффективность?
• Могут ли они честно оценить нагрузку на обслуживание?
• Рассматривают ли они хрупкость тестов и ложные срабатывания?

Кандидаты, которые говорят "да, автоматизируйте всё" или "нет, UI-тесты ненадёжны", упускают суть. Правильный ответ обычно звучит как "всё зависит от того, что это ловит и как часто ломается".

Примерный вопрос #3: Задача на дизайн тестирования

"Мы разрабатываем функцию, которая экспортирует данные пользователя в CSV. Файл может содержать от 10 до 100 000 строк. Что вы будете тестировать? Что вы не будете тестировать и почему?"

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

• Могут ли они расставить приоритеты (формат CSV, граничные случаи с количеством строк, специальные символы) вместо шума (имеет ли значение цвет кнопки)?
• Знают ли они, что стоит автоматизировать, а что проверять выборочно?
• Могут ли они объяснить риск (утечка данных, повреждение форматирования) в отличие от предпочтения?

Хорошие QA-инженеры безжалостны в определении области охвата. Они не тестируют всё; они тестируют то, что может повредить бизнесу.

Примерный вопрос #4: Риск регрессии

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

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

• Хотят ли они запустить полный набор регрессионного тестирования или сначала критически подумают?
• Могут ли они определить, что может сломаться (запросы N+1, неправильная привязка данных)?
• Понимают ли они разницу между "код изменился" и "риск изменился"?

Это разделяет аналитиков и инженеров. Инженеры спрашивают "что изменилось и что имеет значение?" Аналитики запускают полный набор в любом случае.

Примерный вопрос #5: Вопрос о кроссбраузерности (с поворотом)

"Вы тестируете новый UI-компонент на Chrome, Firefox и Safari. Он отображается корректно везде. Вы тестируете его на IE11? На мобильном Chrome? На браузерах на основе Chromium, таких как Edge? Примите решение о компромиссе."

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

• Знают ли они свою пользовательскую базу (не все продукты нуждаются в поддержке IE11)?
• Могут ли они оценить охват браузеров относительно затрат на тестирование?
• Знают ли они разницу между реальными браузерами и поддельным охватом?

Здесь имеет значение мнение. "Мы не поддерживаем IE11, поэтому нет" звучит сильнее, чем "нам следует тестировать всё".

Примерный вопрос #6: Собеседование с живым кодированием (краткое)

"Напишите тестовый случай на любом известном вам фреймворке. Я дам вам простую функцию: validateEmail(email). Верните true, если это корректный email, false в противном случае. Напишите тест — не пишите функцию."

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

• Могут ли они подумать о граничных случаях (пустая строка, нет @, несколько @, пробелы)?
• Пишут ли они понятные или запутанные тесты?
• Знают ли они свой фреймворк тестирования (утверждения, инициализация/очистка)?
• Тестируют ли они поведение или реализацию?

Это собеседование с живым кодированием, которое занимает 10 минут и раскрывает беглость языка, структуру тестирования и стиль мышления.

Паттерн, который работает

Все шесть этих вопросов имеют одинаковую структуру: представьте реальную (или похожую на реальную) ситуацию, попросите кандидата рассуждать о ней, и слушайте суждение, а не вспоминание ключевых слов. Ответы не правильные или неправильные. Они раскрывающие.

Интервью, которые вы запомните, — это те, где кандидат задаёт вам уточняющий вопрос, который заставляет вас остановиться. Вот этот сигнал. Вот это найм.

Когда использовать письменные оценки вместо

Не каждый найм QA требует записанного собеседования с живым кодированием. Задание на take-home тестовый случай может быть одинаково информативным: "Вот спецификация функции. Напишите 10-15 тестовых случаев, которые вы предложили бы своей команде. Объясните ваши приоритеты." Затем задайте дополнительные вопросы в следующем раунде об их логике. Это объединяет качество артефакта с вербальной защитой.

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

Контраргумент

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

Вопросы имеют меньшее значение, чем философия: вы измеряете мышление, а не память. Всё остальное следует отсюда.