Вопросы на собеседовании тестировщику

На собеседовании с тестировщиком мало спросить определения видов тестирования — их легко выучить. Полезнее разбирать реальные ситуации: как человек ищет ошибки в новой функции, как пишет баг-репорт, что делает, когда разработчик говорит «это не баг», и как решает, что тестировать при нехватке времени перед релизом.

12 вопросов с разбором ответов

Расскажите о самой интересной ошибке, которую вы нашли. Как вы на неё вышли?Что важно услышать: Ход рассуждений, нестандартный сценарий, понимание, почему ошибка была важна для пользователей.Настораживает: Пример про опечатку в тексте или не может вспомнить ни одного случая.
Вам дали новую функцию без документации. С чего вы начнёте тестирование?Что важно услышать: Изучение функции, вопросы аналитику или разработчику, составление списка сценариев, позитивные и негативные проверки.Настораживает: «Буду кликать и смотреть, что сломается» без системы.
Как вы пишете баг-репорт? Что обязательно должно в нём быть?Что важно услышать: Шаги воспроизведения, ожидаемый и фактический результат, окружение, данные, критичность, вложения.Настораживает: Не упоминает шаги воспроизведения или ожидаемый результат.
Разработчик закрыл ваш баг со статусом «так и задумано». Вы не согласны. Что дальше?Что важно услышать: Обращение к требованиям, обсуждение с аналитиком или владельцем продукта, спокойная аргументация.Настораживает: Переоткрывает баг снова и снова или сразу сдаётся.
До релиза два часа, а регресс занимает день. Как вы поступите?Что важно услышать: Приоритизация по рискам: критичные сценарии и изменённые области, прозрачное информирование команды о непроверенном.Настораживает: Проверит «что успеет» без приоритетов или промолчит о рисках.
Вспомните случай, когда вы пропустили ошибку в релиз. Что произошло и какие выводы вы сделали?Что важно услышать: Честный разбор, изменение подхода: новые тест-кейсы, проверки, расширение регресса.Настораживает: Утверждает, что ничего не пропускал, или винит разработчиков.
Какие техники тест-дизайна вы применяете? Приведите пример из практики.Что важно услышать: Классы эквивалентности, граничные значения, таблицы решений — на примере реальной задачи.Настораживает: Знает названия, но не может привести пример.
С какими инструментами вы работаете: трекеры, тестовая документация, API, базы данных, браузерные инструменты?Что важно услышать: Конкретный опыт, соответствующий вашим задачам, например проверка запросов или данных в базе.Настораживает: Перечисляет инструменты, но не может рассказать, что делал с ними.
Есть ли у вас опыт автоматизации тестов? Какие проверки вы бы автоматизировали в первую очередь?Что важно услышать: Понимание, что автоматизируют стабильные и часто повторяющиеся сценарии; реальный опыт, если он заявлен.Настораживает: Хочет автоматизировать всё подряд или заявляет опыт, который не подтверждается деталями.
Как вы понимаете, что функция протестирована достаточно?Что важно услышать: Покрытие требований и рисков, критерии завершения, согласование с командой.Настораживает: «Когда закончилось время» или «когда перестал находить баги».
Как вы строите отношения с разработчиками, если постоянно находите ошибки в их коде?Что важно услышать: Фокус на продукте, а не на людях, уважительный тон, готовность помочь воспроизвести.Настораживает: Позиция «я их ловлю», пренебрежительные отзывы о разработчиках.
Что вам интереснее: ручное тестирование, автоматизация или анализ требований?Что важно услышать: Совпадение интересов кандидата с реальными задачами позиции.Настораживает: Рассматривает ручное тестирование лишь как временный шаг, хотя позиция именно такая.

Пример отчёта по кандидату на должность тестировщика

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

Пример отчёта • данные вымышлены

Отчёт по кандидату

Анна К.

Кандидат на должность «Тестировщик» · 5 методик · 38 минут · пройдено полностью

73%

соответствие должности

Среднее соответствиеМожно пригласить — с уточняющими вопросами

Результаты по качествам

Внимательность к деталям8/10
Сильная сторона Выше требований должности — можно опираться с первых недель.
Аналитическое мышление7/10
На уровне требований Соответствует требованиям; стоит поддержать на адаптации.
Чёткость в изложении6/10
На уровне требований Соответствует требованиям; стоит поддержать на адаптации.
Настойчивость5/10
Зона риска Ниже ожидаемого — уточните на собеседовании.
Дипломатичность9/10
Сильная сторона Выше требований должности — можно опираться с первых недель.
Умение расставлять приоритеты9/10
Сильная сторона Выше требований должности — можно опираться с первых недель.

Сильные стороны

Дипломатичность — 9/10: тестировщик постоянно сообщает о чужих ошибках, и важно делать это так, чтобы не портить отношения в команде.
Умение расставлять приоритеты — 9/10: перед релизом всё проверить невозможно, нужно выбрать, что критично для пользователей и бизнеса.
Внимательность к деталям — 8/10: ошибки часто прячутся в мелочах: неверный формат даты, лишний пробел в сумме, кнопка, которая срабатывает дважды.

Риски и зоны внимания

Настойчивость — 5/10. Проверьте подробнее: нестабильные ошибки приходится воспроизводить долго, пробуя разные данные, окружения и последовательности действий.
Чёткость в изложении — 6/10. Проверьте подробнее: баг-репорт должен позволить разработчику воспроизвести ошибку с первого раза, без уточняющих вопросов.

Что спросить на собеседовании

Разработчик закрыл ваш баг со статусом «так и задумано». Вы не согласны. Что дальше?Что важно услышать: Обращение к требованиям, обсуждение с аналитиком или владельцем продукта, спокойная аргументация.
Расскажите о самой интересной ошибке, которую вы нашли. Как вы на неё вышли?Что важно услышать: Ход рассуждений, нестандартный сценарий, понимание, почему ошибка была важна для пользователей.
С какими инструментами вы работаете: трекеры, тестовая документация, API, базы данных, браузерные инструменты?Что важно услышать: Конкретный опыт, соответствующий вашим задачам, например проверка запросов или данных в базе.
Вспомните случай, когда вы пропустили ошибку в релиз. Что произошло и какие выводы вы сделали?Что важно услышать: Честный разбор, изменение подхода: новые тест-кейсы, проверки, расширение регресса.

Рекомендация MERAIQ

Часть требований выполняется уверенно (дипломатичность, умение расставлять приоритеты), но есть зоны риска: чёткость в изложении, настойчивость. Пригласите на собеседование и задайте уточняющие вопросы.

Отчёт помогает принять решение, но не заменяет собеседование. Результаты оценки — ориентир, а не диагноз.

Пройдите оценку как кандидат на эту должность — 5 минут

Готовая оценка для тестировщика за 30 секунд

Тесты из каталога MERAIQ, вопросы для собеседования и анкета-фильтр. Бесплатно и без регистрации.

Создать оценку

Частые ошибки при найме

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

Частые вопросы

Какие вопросы задают тестировщику на собеседовании?

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

Как отличить опытного тестировщика от новичка на собеседовании?

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

Нужно ли просить кандидата протестировать предмет, например ручку или лифт?

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