.svg)
На собеседовании тестировщика проверяют не память на определения, а рабочий способ мышления. Интервьюер хочет понять, как вы ищете риск, формулируете проверку и объясняете найденную проблему.
Ниже собраны вопросы для QA-инженера уровней Junior, Middle и Senior. Мы разберём основы тестирования, документацию, тест-дизайн, API, SQL, инструменты, автоматизацию и рабочие кейсы.
Формулировки могут отличаться от компании к компании. Важно не заучить готовый текст, а уметь связать ответ с задачей, продуктом и своим опытом.
Как проходит собеседование тестировщика
Сначала рекрутер уточняет роль, формат работы и ожидания. На этом этапе достаточно коротко объяснить, какие продукты и задачи вы тестировали, с какими инструментами работали и какой уровень ответственности брали.
Дальше обычно идёт технический разговор. Для Junior это основы тестирования, тест-кейсы, баг-репорты, API и SQL. Для Middle и Senior добавляются стратегия, риски, автоматизация, релизные решения и взаимодействие с командой.
Практическое задание может быть частью технического этапа или отдельным тестовым. Вас могут попросить разобрать экран, составить проверки, найти дефект, проверить запрос или объяснить план тестирования новой функции.
Финальный разговор с руководителем помогает понять, как вы принимаете решения и работаете с неопределённостью. Порядок этапов не фиксирован, поэтому заранее уточните формат у рекрутера.
Какие вопросы задают QA-инженеру
Профессиональный блок обычно состоит из пяти частей: основы тестирования, тестовая документация и дизайн проверок, API и HTTP, SQL и данные, инструменты и процессы команды. Чем выше грейд, тем меньше вопросов на термины и больше на выбор стратегии.
Отдельно спрашивают об опыте, сложных дефектах и спорных решениях. В ситуационных задачах смотрят, как вы расставляете приоритеты, когда данных мало, а релиз близко.
Практика показывает не только знания, но и последовательность действий. Поэтому в ответах полезно проговаривать гипотезу, проверку, результат и следующий шаг.
Проверьте знания QA до собеседования
Пройдите пробное QA-собеседование в ИИ-тренажёре: вопросы под роль и разбор ответов после интервью.
Профессиональные вопросы и ответы для тестировщика
Junior QA: база и рабочие артефакты
Что такое тестирование и какой у него результат?
Что проверяют. Понимание цели работы QA.
Как отвечать. Тестирование - это получение информации о качестве продукта через проверки и анализ рисков. Результат - не только найденные баги, но и понятное команде решение о текущем состоянии продукта.
Чем проверка отличается от подтверждения результата?
Что проверяют. Понимание границ терминов verification и validation.
Как отвечать. Проверка подтверждает, что продукт сделан по заданным требованиям и спецификации. Подтверждение результата отвечает на вопрос, решает ли продукт реальную задачу пользователя. Пример лучше связать с конкретным требованием и пользовательским сценарием.
Какие уровни и виды тестирования вы используете?
Что проверяют. Умение выбрать подход под риск, а не перечислить термины.
Как отвечать. Назовите уровень проверки, например модульный, интеграционный или системный, и отдельно вид, например функциональный, регрессионный или исследовательский. Затем объясните, какую ошибку каждый подход помогает поймать.
Чем тест-кейс отличается от чек-листа?
Что проверяют. Понимание тестовой документации.
Как отвечать. Тест-кейс фиксирует подробные шаги, данные и ожидаемый результат. Чек-лист оставляет короткий список проверок и подходит для повторяющихся или исследовательских прогонов, где важна скорость.
Что должно быть в хорошем баг-репорте?
Что проверяют. Умение сделать дефект воспроизводимым.
Как отвечать. Укажите окружение, предусловия, шаги, фактический и ожидаемый результат, частоту воспроизведения и вложения. Заголовок должен сразу описывать проблему, а не только экран, на котором она встретилась.
Как различаются severity и priority?
Что проверяют. Умение отделять технический ущерб от порядка работы.
Как отвечать. Severity описывает тяжесть последствий для продукта, а priority - срочность исправления. Критичный дефект может ждать, если функция выключена фиче-флагом, а небольшой дефект в рекламной акции иногда получает высокий приоритет.
Как применить классы эквивалентности и граничные значения?
Что проверяют. Знание базового тест-дизайна.
Как отвечать. Разделите входы на группы с одинаковым поведением и отдельно проверьте границы. Для поля от 1 до 100 это будут значения ниже границы, на границе, внутри диапазона и выше верхней границы.
Что такое smoke и regression testing?
Что проверяют. Понимание цели разных прогонов.
Как отвечать. Smoke быстро отвечает, можно ли продолжать проверку сборки. Regression показывает, не сломались ли уже работавшие сценарии после изменений. Набор регрессии выбирают по риску, а не запускают одинаково для любого релиза.
Какие HTTP-методы и статусы нужно знать QA?
Что проверяют. Базовое понимание API.
Как отвечать. Объясните назначение GET, POST, PUT, PATCH и DELETE, а затем свяжите статусы с результатом запроса: 2xx, 4xx и 5xx. Важно сказать, что статус нужно проверять вместе с телом ответа и побочными эффектами.
Как проверить JSON-ответ без ручного просмотра каждой строки?
Что проверяют. Практический подход к API-проверкам.
Как отвечать. Сначала проверяют статус и обязательные поля, затем типы, значения и связи между полями. Для повторяемых проверок используют assertions в Postman или автотест, а случайные данные и даты сравнивают по правилам, а не по точной строке.
Какой SQL-запрос вы напишете для поиска дублей?
Что проверяют. Умение работать с данными.
Как отвечать. Сгруппируйте записи по ключевому полю и оставьте группы с count больше одного. В ответе назовите таблицу, поле и условие, а также предупредите, что проверка должна учитывать статус удалённых или архивных записей.
Что вы проверяете в DevTools?
Что проверяют. Знакомство с браузерными инструментами.
Как отвечать. В Network смотрю запрос, статус, заголовки, payload и ответ. В Console ищу ошибки JavaScript, а в Application проверяю cookies, storage и service worker, если они участвуют в сценарии.
Middle QA: API, данные и риски
Как выбрать набор проверок для новой функции?
Что проверяют. Умение работать с риском и неполными требованиями.
Как отвечать. Сначала уточните цель функции и самые дорогие ошибки. Затем выделите критические пользовательские пути, интеграции, негативные сценарии и совместимость. После этого решите, что проверять вручную, что автоматизировать и что оставить на исследовательский прогон.
Как тестировать API с авторизацией?
Что проверяют. Понимание жизненного цикла доступа.
Как отвечать. Проверяйте успешный запрос, отсутствие токена, просроченный токен, чужой ресурс и недостаточную роль. Отдельно смотрите, не попадают ли секреты в логи, URL или сообщения об ошибках.
В чём практическая разница PUT и PATCH?
Что проверяют. Понимание семантики обновления.
Как отвечать. PUT обычно описывает полную замену ресурса, PATCH - частичное изменение. Важно проверить повторный запрос, обязательные поля, отсутствие изменений в соседних данных и корректный ответ сервера.
Как проверить контракт между фронтендом и API?
Что проверяют. Умение ловить интеграционные дефекты.
Как отвечать. Зафиксируйте схему запроса и ответа, обязательные поля, типы, коды ошибок и версию контракта. Проверьте реальный ответ на пограничных данных и убедитесь, что клиент корректно обрабатывает добавление или отсутствие необязательного поля.
Что будете делать, если SQL-запрос возвращает неверные данные?
Что проверяют. Умение локализовать проблему в данных и запросе.
Как отвечать. Сначала воспроизведите запрос на минимальном наборе данных. Затем проверьте join, фильтры, null, дубликаты и часовой пояс. Сравните результат с эталонной выборкой и только после этого делайте вывод о дефекте приложения.
Как отличить flaky-тест от исправленного дефекта?
Что проверяют. Понимание нестабильности автопроверок.
Как отвечать. Повторите тест в одинаковом окружении, соберите логи и найдите зависимость от времени, данных, сети или порядка запуска. Flaky-тест не следует просто перезапускать до зелёного результата: причину нужно записать и контролировать.
Когда автоматизация не окупится?
Что проверяют. Зрелый выбор между ручной и автоматической проверкой.
Как отвечать. Не стоит автоматизировать одноразовый сценарий, нестабильный интерфейс или проверку, где подготовка данных дороже ручного прогона. Автоматизация полезнее там, где сценарий повторяется, стабилен и снижает заметный риск.
Как сообщить команде, что релиз рискован?
Что проверяют. Умение говорить о качестве через факты.
Как отвечать. Покажите покрытые и непокрытые области, список открытых дефектов, влияние на пользователя и остаточные риски. Вместо общего «нельзя выпускать» предложите варианты: исправить, ограничить фичу, включить мониторинг или принять риск владельцем продукта.
Какие метрики QA действительно полезны?
Что проверяют. Понимание ограничений метрик.
Как отвечать. Смотрите на escaped defects, долю повторно открытых дефектов, стабильность прогонов, время обратной связи и покрытие критических сценариев. Число тест-кейсов само по себе не показывает качество и может стимулировать формальную работу.
Как тестировать длинную операцию или фоновой процесс?
Что проверяют. Умение проверять асинхронные сценарии.
Как отвечать. Проверьте запуск, промежуточный статус, повторный запрос, таймаут, повторную обработку и финальный результат. Для каждого состояния нужны понятные условия завершения и защита от дублей.
Что делать с неполными требованиями?
Что проверяют. Навык уточнения требований до тестирования.
Как отвечать. Соберите вопросы по цели, ролям, данным, ошибкам и ограничениям. Зафиксируйте допущения и попросите владельца подтвердить их. Не молча превращайте пробелы в поведение продукта.
Senior QA: стратегия и качество релиза
Как построить стратегию тестирования нового продукта?
Что проверяют. Системное мышление и связь качества с риском.
Как отвечать. Начните с пользователей, критических потоков, архитектуры и ограничений релиза. Опишите уровни проверок, тестовые данные, окружения, автоматизацию, мониторинг и критерии готовности. Стратегия должна объяснять, какие риски мы покрываем, а не просто перечислять виды тестирования.
Как распределить проверки в тестовой пирамиде?
Что проверяют. Понимание стоимости обратной связи.
Как отвечать. Большую часть стабильных проверок оставляйте на нижних уровнях, интеграционные сценарии добавляйте для контрактов, а UI-тесты используйте для небольшого числа критических путей. Пирамида не запрещает ручное тестирование, а помогает не строить всё покрытие на дорогом UI-слое.
Когда выпускать при наличии открытых дефектов?
Что проверяют. Умение принимать решение в условиях компромисса.
Как отвечать. Оцените влияние, вероятность, обходной путь, аудиторию и стоимость отката. Зафиксируйте решение владельца продукта и добавьте контроль: фиче-флаг, мониторинг, план исправления или ограничение аудитории.
Как проверять качество релиза после выкладки?
Что проверяют. Понимание post-release контроля.
Как отвечать. Сделайте smoke на проде, проверьте ключевые метрики, логи, ошибки и бизнес-события. Сценарии должны быть безопасными и заранее согласованными, чтобы проверка не создавала реальные заказы или платежи.
Как расследовать дефект, который не воспроизводится?
Что проверяют. Навык работы с неопределённостью.
Как отвечать. Соберите точную версию, данные, время, пользователя, логи и трассировку. Сравните успешный и неуспешный сценарии, добавьте наблюдаемость и проверьте гипотезы по одной. Формулировка «не повторилось» не заменяет расследование.
Как выстраивать quality gates в CI?
Что проверяют. Понимание автоматических ограничений релиза.
Как отвечать. Разделите быстрые обязательные проверки и более долгие проверки по расписанию или перед важным окружением. Красный gate должен блокировать только доказанный риск, а flaky-проверки нужно чинить, а не скрывать ретраями.
Как объяснить команде пользу исследовательского тестирования?
Что проверяют. Умение защищать подход без догм.
Как отвечать. Покажите, какие неизвестные и связи не покрывает сценарный набор. Зафиксируйте миссию сессии, ограничения и наблюдения, чтобы исследовательский прогон стал воспроизводимым источником решений.
Как менторить Junior QA на реальной задаче?
Что проверяют. Лидерские навыки и качество обратной связи.
Как отвечать. Дайте контекст, критерии результата и небольшую самостоятельную область. Просите объяснить ход мысли, разбирайте не только ошибку, но и способ её заметить, затем постепенно увеличивайте ответственность.
Потренируйтесь отвечать на вопросы QA
ИИ-тренажёр задаст вопросы под роль QA и покажет разбор ваших ответов.
Какие вопросы задают о вашем опыте
Для Junior подойдут учебный проект, курс, пет-проект или тестовое задание. Важно не выдавать его за коммерческий опыт, а честно объяснить задачу, свои проверки и то, чему научились.
Middle стоит подготовить историю о сложном дефекте, спорном приоритете и взаимодействии с разработчиком. Покажите контекст, варианты, принятое решение и результат, а не только список инструментов.
Senior обычно спрашивают о влиянии на процесс. Подготовьте пример, где вы изменили стратегию, ускорили обратную связь, снизили риск релиза или помогли команде договориться о качестве.
Какие ситуационные вопросы задают QA
После релиза выросли ошибки, но баг не воспроизводится
Зафиксируйте время, версии, сегмент пользователей и симптомы. Затем сопоставьте логи и метрики, ограничьте распространение проблемы и предложите безопасный план отката или фиче-флага.
Разработчик не согласен с багом
Сначала сверяйте ожидание с требованием и пользовательским сценарием. Покажите минимальные шаги и данные, а при спорном требовании подключите владельца продукта, не переводя разговор в личный конфликт.
До релиза один час, а регрессия не завершена
Разделите критические пути и второстепенные проверки, сообщите остаточный риск и предложите ограниченный выпуск. Не называйте релиз безопасным только потому, что успели пройти часть списка.
В API меняется формат ответа
Уточните контракт и обратную совместимость, проверьте клиентов и версии. Если миграция поэтапная, тестируйте оба формата и заранее добавьте контроль ошибок.
Какие практические задания дают QA
Составьте проверки для формы регистрации
Начните с обязательных полей и валидных данных, затем добавьте границы, дубли, пробелы, локаль, ошибки сети, повторную отправку и доступность. Отдельно назовите критический путь регистрации.
Разберите API-метод
Проверьте метод, URL, авторизацию, заголовки, тело, статусы, схему ответа и побочные эффекты. Добавьте негативные сценарии: неверный идентификатор, отсутствие поля, чужой ресурс и повторный запрос.
Найдите причину неверного отчёта
Сначала сравните данные в интерфейсе с API и базой. Затем проверьте фильтры, даты, часовой пояс, join и кеш. Результат оформите как воспроизводимый дефект с минимальным набором данных.
Как подготовиться к собеседованию тестировщика
Перед собеседованием на позицию тестировщика стоит освежить основные темы по тестированию и потренироваться отвечать на вопросы вслух. Для такой тренировки можно пройти пробное интервью в ИИ-тренажёре HireHi — он задаёт вопросы с учётом специальности и выбранного формата собеседования, принимает ответы голосом, а после завершения показывает разбор результатов и рекомендации по подготовке.
Шаг 1. Выберите роль, грейд и формат
В тренажёре укажите QA, Manual QA, свой грейд и формат интервью. Так вопросы будут ближе к роли, а подготовка не превратится в общий список терминов.
Шаг 2. Запустите тренировку и отвечайте
В реальном прогоне отвечайте голосом и проговаривайте ход мысли. Для QA полезно называть риск, проверку, ожидаемый результат и следующий шаг, а не только выдавать определение.
Шаг 3. Изучите результат
После завершения разбора сравните сильные стороны с зонами роста. Отдельно выпишите вопросы, где ответ был правильным по сути, но не хватило структуры или примера.
Шаг 4. Повторите слабые темы
Повторите только проблемные темы и снова пройдите короткий прогон. Такой цикл полезнее, чем ещё раз перечитать весь список вопросов.
Проверьте готовность к QA-интервью
Пройдите пробное QA-собеседование с вопросами под выбранную роль и разбором ответов.
Как вести себя на собеседовании QA
Начинайте с уточнения задачи и ограничений. Если данных не хватает, назовите допущение и спросите, верно ли оно, вместо того чтобы молча выбирать случайный сценарий.
В ответах разделяйте факт, гипотезу и результат проверки. Когда не знаете термин, честно скажите об этом и покажите, как нашли бы информацию или проверили поведение продукта.
Не спорьте о приоритете без контекста. Объясняйте влияние на пользователя, вероятность, обходной путь и стоимость исправления.
Какие вопросы задать работодателю QA
- Какие риски сейчас самые дорогие для продукта?
- Как устроены требования и кто принимает решение по спорным ожиданиям?
- Какие проверки входят в CI и что блокирует релиз?
- Как команда работает с багами, которые не воспроизводятся?
- Как распределены ручные и автоматизированные проверки?
- Каким будет результат работы QA в первые три месяца?