Что на самом деле проверяют на собеседовании QA-инженера?

Кто присутствует и что проверяет

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

Что они проверяют под прикрытием светской беседы — это можете ли вы найти проблемы, которые упустит разработчик, можете ли вы описать баг настолько точно, что кто-то другой сможет воспроизвести его без дополнительных вопросов, и понимаете ли вы, зачем существует тест, а не только как его запустить. Ничто из этого не проявится, если вы только заучиваете определения терминов тестирования.

Практическое задание: как оно выглядит

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

• Исследовательское тестирование в реальном времени. Вам дают небольшое веб-приложение, staging-сборку или иногда просто публичный сайт и просят найти баги за пятнадцать-двадцать минут, озвучивая свои мысли. Что они наблюдают — это ваш метод: начинаете ли вы с очевидного happy path и останавливаетесь на этом, или переходите к граничным значениям, неожиданному вводу, обработке сессий, поведению кнопки «Назад» браузера и параллельным действиям?
• Разработка тест-кейсов на бумаге или в общем документе. Вам дают описание функции, иногда настолько расплывчатое, как одно предложение вроде «пользователь может сбросить пароль», и просят написать тест-кейсы. Это проверяет, думаете ли вы о негативных случаях, истёкших токенах, ограничении частоты запросов и состояниях аккаунта, а не только умеете ли форматировать таблицу.
• Задание на написание баг-репорта. Вам показывают дефект и просят его описать, или дают плохо написанный баг-репорт и просят его раскритиковать. Они ищут шаги воспроизведения, детали окружения, ожидаемый и фактический результат, разумное разделение серьёзности и приоритета — а не абзац текста.
• Задание на автоматизацию с кодом. Для позиций, близких к SDET, вас попросят написать или расширить тест с использованием Selenium, Playwright или Cypress, иногда на реальном тестовом приложении, которое они предоставляют. Интервьюеров интересует стратегия селекторов (тянетесь ли вы к хрупкому XPath или стабильному data-test атрибуту), ожидания (явные против произвольных sleep-вызовов) и переживёт ли ваш тест небольшое изменение UI.
• Задание на SQL или API. Если роль затрагивает backend-тестирование, ожидайте задачу на запрос — проверку целостности данных после миграции или проверку join на дублирующиеся записи — или запрос, написанный в Postman к документированному API, с проверкой кодов статуса, схемы ответа и обработки ошибок.

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

Вопросы, которые звучат как светская беседа, но не являются ею

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

«Расскажите о баге, который вы нашли, а никто другой не заметил». Это не просьба о боевой истории. Это проверка того, понимаете ли вы, почему баг упустили — был ли это граничный случай в обработке дат между часовыми поясами, race condition под нагрузкой, регрессия, внесённая обновлением зависимости — и можете ли вы описать рассуждения, которые вас туда привели, а не только результат.

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

«В чём разница между smoke-тестом и regression suite, и когда вы запускаете каждый?» Определения есть в любом учебнике. Что отличает настоящий ответ — это размещение их в пайплайне: smoke-тесты запускаются на каждой сборке, чтобы быстро поймать сломанный деплой, regression suite запускаются перед релизом или по расписанию, потому что они медленнее и дороже, а зрелая команда помечает тесты, чтобы CI мог выбрать подмножество для запуска в зависимости от того, что изменилось.

«Расскажите о случае, когда вы не согласились с разработчиком о том, является ли что-то багом». Это тестирует суждение и коммуникацию при разногласиях, а не избегание конфликтов. Хороший ответ называет фактический критерий, использованный для разрешения — спецификацию, критерии приёмки, продуктовое решение — а не просто «мы это обсудили».

«Как вы решаете, что не тестировать?» Это один из самых показательных вопросов всего собеседования, потому что нетестируемый скоуп и приоритизация на основе рисков — это то, о чём поверхностный кандидат никогда не задумывался. Тот, кто отгружал продукт в условиях дедлайна, будет говорить о риске, частоте использования и радиусе поражения. Тот, кто этого не делал, скажет «я стараюсь тестировать всё».

Как звучит поверхностный ответ

Опытный интервьюер может определить за минуту или две, когда кандидат декламирует, а не рассуждает. Признаки конкретны:

• Правильное определение терминов — smoke testing, sanity testing, regression, exploratory testing — но никогда не связывание их с пайплайном, релизным циклом или реальным решением о том, когда что запускать.
• Говорят «я тестирую граничные случаи и граничные значения», не называя ни одного граничного случая для фичи, которая на самом деле перед ними.
• Описание опыта автоматизации только через использованные инструменты («я использовал Selenium и Cypress») без упоминания того, что делало suite нестабильным, как они отлаживали падающий тест в CI, или как решали, что автоматизировать, а что оставить ручным.
• Написание баг-репорта в задании, где есть описание, но нет шагов воспроизведения, нет окружения и нет чёткой серьёзности — именно такой репорт отклоняется разработчиком в реальных командах.
• Ответ на «как бы вы протестировали X» только happy path или исчерпывающим списком, не показывающим чувства приоритета, когда спрашивают, что они сделают с ограниченным временем.
• Заявление о знакомстве с конкретным инструментом — TestRail, Zephyr, BrowserStack, JMeter — но неспособность описать одну конкретную вещь, которую они в нём сделали, кроме «записывал результаты тестов».

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

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

Выберите два-три бага из своей работы, которые можете описать меньше чем за девяносто секунд каждый: каким был симптом, как вы изолировали причину и почему это было важно. Приготовьте пример, где вы не согласились с разработчиком или product owner о серьёзности и как это разрешилось. Если роль перечисляет конкретный фреймворк автоматизации, напишите небольшой тест на нём заранее, а не только читайте о нём — интервьюеры спрашивают о стратегии локаторов и ожиданиях, потому что это то, что отделяет того, кто запускал suite, от того, кто его скопировал. Если вероятно тестовое задание на дом или живое упражнение, относитесь к формату баг-репорта так же серьёзно, как к самому багу; чистый, воспроизводимый репорт часто именно то, что оценивает собеседование.

И внимательно прочитайте само объявление о работе перед звонком — упомянутые инструменты, типы тестов и процесс релиза (ручная регрессия, CI-driven, только исследовательское) подскажут, какие из вышеперечисленных вопросов будут важнее всего. jobmarket.pro читает это объявление полностью и готовит отклик из вашей реальной истории работы под него, так что соответствие, на которое он вас направляет — это то, которое вы сможете защитить под таким допросом.