Собеседование на QA-инженера: 23 вопроса с ответами для подготовки
Интервьюер открывает форму регистрации с одним полем «Возраст» и просит: «Протестируйте». Он смотрит, начнёте ли вы сразу вбивать случайные числа или сначала спросите, какие значения допустимы, разобьёте ввод на классы, проверите границы и вспомните про пустое поле, пробелы, буквы и очень длинную строку.
Ниже — этапы собеседования, разбор вопросов по теории тестирования, тест-дизайну, документации, баг-репортам, API, SQL и автоматизации, вопросы об опыте, кейсы, тестовые задания и вопросы, которые стоит задать работодателю.
Главное, что проверяют у QA-инженера, — умеет ли он находить риски, а не только прогонять сценарии: что сломается у пользователя, как это воспроизвести и как не допустить повторения. Работодатели ждут и технической базы: в топе ключевых навыков вакансий QA-инженера на РаботаМакс (559 активных вакансий, срез 21 октября 2026) — SQL (101 упоминание), Python (63) и Git (60).
Как проходит собеседование QA-инженера
| Этап | Что проверяют | Как подготовиться |
|---|---|---|
| Скрининг с рекрутером | Опыт, тип проектов, ручное или автоматизация, ожидания по деньгам | Рассказ о себе на полторы минуты и вилка, которую готовы назвать |
| Техническое интервью | Теорию тестирования, тест-дизайн, баг-репорты, API, SQL | Чек-лист ниже и пример из своего проекта к каждой теме |
| Практическая часть | Как вы тестируете вживую: форму, страницу, запрос в Postman | Тренироваться вслух: сначала уточнить требования, потом проверки |
| Секция автоматизации | Код автотестов, фреймворк, CI | Разобрать свой проект с автотестами: структура, отчёты, запуск в пайплайне |
| Финал с тимлидом | Как вы работаете с разработкой и отвечаете за качество релиза | Две истории: пропущенный баг и спор о приоритете дефекта |
Чем выше грейд, тем меньше вопросов «что такое» и больше «как вы выстроите тестирование». Junior проверяют на теории, тест-дизайне, баг-репортах и простом SQL. Middle — ещё на API, автотестах, регрессе и работе с CI. Senior — о стратегии: что автоматизировать и как договориться о критериях готовности релиза. В крупных компаниях этапов обычно больше, в небольших командах техническое интервью и финал совмещают. Больше всего вакансий QA-инженера в срезе РаботаМакс у Сбербанка (32), Яндекса (21) и IBS (13).
Какие вопросы задают на собеседовании QA-инженера
- Теория тестирования: виды и уровни тестирования, пирамида, жизненный цикл дефекта.
- Тест-дизайн: классы эквивалентности, граничные значения, таблицы решений, переходы состояний.
- Документация и дефекты: чек-листы, тест-кейсы, баг-репорты, приоритет и серьёзность.
- API и базы данных: HTTP, REST, коды ответов, Postman, SQL-запросы с JOIN и группировкой.
- Автоматизация: Python или Java, Selenium или Playwright, Page Object, стабильность тестов.
- Инфраструктура и процесс: Git, CI, Docker, логи в Linux, регресс и смоук перед релизом.
Что чаще всего указывают в ключевых навыках сами работодатели:
| Ключевой навык | Упоминаний |
|---|---|
| SQL | 101 |
| Python | 63 |
| Git | 60 |
| Функциональное тестирование | 56 |
| Postman | 53 |
| Ручное тестирование | 48 |
| Java | 44 |
| Linux | 38 |
| Docker | 37 |
| Регрессионное тестирование | 36 |
| PostgreSQL | 31 |
| API | 30 |
| REST | 28 |
Топ ключевых навыков в вакансиях QA-инженера на РаботаМакс, срез 21 октября 2026 (559 активных вакансий): число вакансий среза, где навык указан.
Вопросы и ответы на собеседовании QA-инженера
Вопросы сгруппированы по темам, а не по грейдам: junior и senior спрашивают об одном и том же, разница — в глубине ответа. От junior ждут определение и пример, от middle — случай из проекта, от senior — решение на уровне процесса. Примеры в ответах условные.
Теория тестирования
Чем верификация отличается от валидации?
Понимаете ли вы, что продукт можно сделать «по ТЗ», но не тот, что нужен.
Верификация отвечает на вопрос «правильно ли мы делаем продукт»: соответствует ли он требованиям и спецификации. Валидация — «тот ли продукт мы делаем»: решает ли он задачу пользователя. Пример: кнопка оплаты сделана по ТЗ, но пользователи её не находят.
Выучить определения и не привести ни одного примера из практики.
Что такое пирамида тестирования и зачем она нужна?
Понимаете ли вы цену разных уровней тестов.
Внизу — много быстрых и дешёвых юнит-тестов, в середине — интеграционные и API-тесты, наверху — немного медленных UI-тестов. Чем выше уровень, тем тест дороже в поддержке и тем чаще падает не из-за бага. Поэтому проверку бизнес-логики выгоднее опускать на уровень API, а через UI оставлять ключевые пользовательские сценарии.
Предлагать покрыть всё UI-автотестами: набор получится медленным и нестабильным.
Чем смоук отличается от регрессионного тестирования?
Понимаете ли вы, когда и зачем запускают каждый набор.
Смоук — короткая проверка, что сборка вообще пригодна для тестирования: приложение запускается, вход и основной сценарий работают. Регресс — проверка, что новые изменения не сломали уже работавший функционал; он шире и дольше. Смоук — на каждой сборке, регресс — перед релизом.
Называть регрессом повторную проверку исправленного бага — это ретест.
Тест-дизайн и тестовая документация
Поле принимает возраст от 18 до 65. Какие значения проверите?
Владеете ли вы классами эквивалентности и граничными значениями.
Классы: меньше 18, от 18 до 65, больше 65 и невалидный ввод. Границы: 17, 18, 65, 66, иногда ещё 19 и 64. Отдельно — пустое поле, ноль, дробь, буквы, длинная строка.
Проверить только 18 и 65 или перечислить двадцать случайных значений без логики.
Когда достаточно чек-листа, а когда нужен тест-кейс?
Умеете ли вы выбирать уровень детализации документации.
Чек-лист — список проверок без шагов: подходит, когда команда знает продукт и сроки сжатые. Тест-кейс — с предусловиями, шагами, данными и ожидаемым результатом: нужен для сложной логики, регресса, который выполняют разные люди, и для будущей автоматизации.
«Тест-кейсы всегда лучше» — подробная документация, которую никто не обновляет, быстро устаревает.
Как применить таблицу решений?
Видите ли вы комбинации условий, а не отдельные поля.
Когда результат зависит от нескольких условий сразу. Пример: скидка зависит от карты лояльности и суммы заказа — четыре комбинации, у каждой свой ожидаемый результат. Таблица показывает пропущенные случаи.
Проверить каждое условие отдельно и пропустить их сочетание.
Баг-репорты и жизненный цикл дефекта
Из чего состоит хороший баг-репорт?
Сможет ли разработчик воспроизвести баг по вашему описанию без вопросов.
Короткий заголовок по схеме «что — где — при каком условии», окружение и версия сборки, шаги воспроизведения, фактический и ожидаемый результат, серьёзность и приоритет, вложения: скриншот, видео, логи, запрос и ответ. Один баг — один репорт.
Заголовок «Не работает оплата» и шаги без тестовых данных.
Чем серьёзность отличается от приоритета?
Понимаете ли вы разницу между техническим влиянием и бизнес-срочностью.
Серьёзность — насколько дефект ломает систему. Приоритет — как срочно его нужно исправить. Опечатка в названии компании на главной странице — низкая серьёзность, но высокий приоритет.
Считать, что эти поля всегда совпадают, или ставить всем багам «критический».
Разработчик закрыл ваш баг со статусом «не воспроизводится». Что сделаете?
Как вы работаете с разработкой и доводите дефект до конца.
Перепроверю на актуальной сборке и в том же окружении. Если баг есть — дополню репорт тем, чего не хватало: данные, роль пользователя, браузер, логи, видео. При разногласии проще показать баг вживую.
Молча переоткрыть баг без новой информации.
API и SQL
Как будете тестировать REST API создания заказа?
Знаете ли вы, что проверять кроме кода 200.
Позитивный сценарий: код ответа, тело и его схема, что заказ действительно появился — через GET или запросом в базу. Негативные: пустое тело, неверные типы, лишние и отсутствующие обязательные поля, граничные значения, запрос без токена и с чужим токеном. Отдельно — повторная отправка того же запроса: не создастся ли второй заказ.
Проверить только статус ответа и не заглянуть в данные.
Какие коды ответа HTTP знаете и что они означают?
Понимаете ли вы, где ошибка клиента, а где сервера.
2xx — успех: 200 OK, 201 Created, 204 No Content. 3xx — перенаправление. 4xx — ошибка запроса: 400 неверные данные, 401 нет авторизации, 403 нет прав, 404 не найдено, 409 конфликт. 5xx — ошибка сервера: 500, 502, 503. Неверный ввод должен давать 4xx, а не 500.
Путать 401 и 403 или считать ответ 500 на пустое поле нормой.
Напишите запрос: пользователи, у которых больше трёх заказов
Владеете ли вы JOIN и группировкой.
Соединяем таблицы users и orders по user_id, группируем по пользователю и фильтруем через HAVING COUNT(*) > 3. Дальше объясните разницу: WHERE фильтрует строки до группировки, HAVING — после.
Поставить условие на COUNT в WHERE.
Автоматизация и инфраструктура
Что автоматизировать в первую очередь?
Умеете ли вы считать отдачу от автотестов.
Стабильные и часто повторяемые сценарии с высоким риском: регресс основного пути пользователя, смоук, проверки API, расчёты с большим числом комбинаций данных.
«Автоматизировать всё» — набор вырастет быстрее, чем вы успеете его поддерживать.
Почему UI-автотесты бывают нестабильными и как с этим бороться?
Работали ли вы с реальным набором автотестов.
Частые причины: фиксированные паузы вместо ожиданий, хрупкие локаторы по вёрстке, зависимость тестов друг от друга и от общих данных, нестабильное окружение. Решения: явные ожидания, устойчивые локаторы, Page Object, независимые тестовые данные.
Лечить нестабильность увеличением задержек и автоматическими перезапусками.
Как автотесты встроены в CI и что вы делаете, когда сборка упала?
Понимаете ли вы место тестов в процессе поставки.
Тесты лежат в Git рядом с кодом или в отдельном репозитории и запускаются в пайплайне на каждый мерж-реквест или по расписанию; окружение часто поднимают в Docker. Если сборка упала — по отчёту и логам понять: баг продукта, теста или окружения. Для разбора нужен Linux: логи сервиса, grep, состояние контейнера.
Считать, что пайплайн — зона только DevOps-инженера.
Вопросы о мотивации и о себе
Общие вопросы
- «Расскажите о себе». Полторы минуты: чем занимаетесь сейчас (продукт, тип тестирования, стек) → один результат → почему ищете новое место. Условный пример: «Три года тестирую мобильное приложение банка: API в Postman, SQL, последние полгода пишу автотесты на Python. Собрал регрессионный набор для API, и ручной регресс перед релизом сократился с двух дней до одного. Хочу больше автоматизации».
- «Почему уходите?» Говорите о том, к чему идёте: хочу расти в автоматизации, хочу продукт с большой аудиторией, хочу участвовать в требованиях с самого начала. Без претензий к работодателю.
- «Почему именно мы?» Одна конкретная деталь: продукт, которым вы пользуетесь и в котором уже замечали проблемы, стек из вакансии, доклад команды.
Если нет опыта или меняете профессию
Первый вопрос к новичку почти всегда о том, как вы учились и что тестировали сами. Вместо коммерческого опыта покажите портфолио: баг-репорты на открытый сайт или приложение, набор чек-листов и тест-кейсов на понятную функцию, коллекцию Postman для публичного API, несколько SQL-запросов к учебной базе и небольшой проект с автотестами в Git. Если переходите из поддержки или аналитики — расскажите о близких задачах: воспроизведение проблем, проверка данных запросами. Как оформить это в резюме — в статье Как составить резюме QA-инженера.
Какие вопросы задают об опыте работы QA-инженера
Расскажите о баге, который дошёл до продакшена.
Честность и умение делать выводы для процесса.
Что за баг и как о нём узнали → почему его не поймали → что изменили. Условный пример: после релиза у части пользователей не применялся промокод, потому что тестовые данные не покрывали заказы с несколькими товарами. Добавили этот случай в регресс.
«У нас багов в проде не было» или перекладывание вины на разработчиков.
Как вы выстраивали или улучшали процесс тестирования?
Выполняли ли вы задачи или влияли на процесс.
Условный пример: регресс шёл вручную по устаревшим тест-кейсам. Я разделил их по приоритету, критичные сценарии API покрыл автотестами в CI, а ручной регресс сфокусировал на изменённых модулях.
Перечислить инструменты вместо описания решения и результата.
Как вы тестировали фичу со сжатыми сроками?
Умеете ли вы приоритизировать по рискам.
Расскажите, как определили самое рискованное: основной путь пользователя, деньги, данные, интеграции. Что проверили полностью, что поверхностно, что сознательно отложили и как сообщили об этом команде. Сильный ответ: риски названы до релиза.
«Работал по ночам и проверил всё» — это про героизм, а не про подход.
Масштаб описывайте конкретно: число пользователей или релизов в месяц, размер регрессионного набора, сколько времени занимал регресс до и после. Разделяйте «мы» и «я». Результат — через то, что изменилось для продукта: меньше дефектов после релиза, быстрее регресс.
Какие ситуационные вопросы могут задать QA-инженеру
Релиз завтра, вы нашли серьёзный баг. Что делаете?
Умение оценить риск и донести его до тех, кто принимает решение.
Сразу заводите баг с понятным описанием и воспроизведением и сообщаете тимлиду и менеджеру, не дожидаясь планёрки. Оцениваете влияние: сколько пользователей затронет, есть ли обходной путь, можно ли отключить функцию. Решение о релизе принимает команда, ваша задача — дать факты.
Молча ждать, пока баг заметят, или самому объявить, что релиза не будет.
Требований нет, есть только макет. Как будете тестировать?
Как вы работаете с неопределённостью.
Собрать то, что есть: макет, похожие функции в продукте, ответы аналитика или разработчика. Выписать вопросы и допущения и согласовать их до начала проверки. Параллельно — чек-лист по макету и исследовательское тестирование.
Отказаться тестировать до появления ТЗ или тестировать молча по своим догадкам.
Разработчик говорит: «Это не баг, а фича». Как поступите?
Умение спорить по фактам, а не по эмоциям.
Опереться на источник: требования, макет, поведение в похожих местах продукта, ожидания пользователя. Если требование не описывает случай — подключить аналитика или продакт-менеджера, они решают, как должно быть. Итог зафиксировать в задаче.
Настаивать на своём без аргументов или сразу уступить, не уточнив требования.
Какие практические задания дают QA-инженеру
Протестируйте форму входа: составьте чек-лист и найдите баги на тестовом стенде
Тест-дизайн, полноту проверок и качество баг-репортов.
Уточните требования к логину и паролю. Затем чек-лист по группам: позитивные сценарии, валидация полей, граничные значения, безопасность (пароль скрыт, нет подсказки, какое из полей неверно), поведение на мобильном, восстановление пароля. Найденные дефекты оформите отдельными баг-репортами с шагами и ожидаемым результатом.
Сдать двадцать однотипных проверок валидации и забыть про сценарии пользователя.
Напишите автотесты для публичного API и выложите в Git
Структуру проекта, читаемость кода, проверки и запуск.
Проект на Python с pytest или на Java с JUnit: позитивные и негативные проверки, вынесенные тестовые данные и базовый URL, понятные названия тестов. В README — как запустить одной командой и что покрыто.
Один длинный тест на всё, захардкоженные данные и отсутствие инструкции по запуску.
Красные флаги тестового задания
Объём тестового стоит уточнять ещё на скрининге. Насторожитесь, если:
- задание выглядит как реальный кусок их продукта, который нужно протестировать целиком;
- на него требуется больше пары вечеров, а об оплате не говорят;
- нет критериев оценки и срока, когда вы получите ответ.
Можно предложить вместо него разобрать ваш проект с автотестами.
Как подготовиться к собеседованию QA-инженера
Начните с вакансии: выпишите требования и стек и сверьте их с чек-листом.
- Теория и тест-дизайн: виды тестирования, пирамида, классы эквивалентности, границы, таблицы решений.
- Документация и дефекты: чек-лист, тест-кейс, баг-репорт, серьёзность и приоритет.
- API: HTTP-методы, коды ответов, REST, коллекция в Postman с проверками.
- SQL: SELECT, JOIN, GROUP BY, HAVING, подзапросы на учебной базе.
- Автоматизация и инфраструктура: язык из вакансии, фреймворк, Git, Docker, базовые команды Linux.
- Три истории из опыта: пропущенный баг, спор с разработчиком, улучшение процесса.
Как вести себя на собеседовании QA-инженера
| Ситуация | Слабо | Сильно |
|---|---|---|
| Просят протестировать предмет или форму | Сразу перечислять проверки | Уточнить, кто пользователь и какие требования, потом идти по классам |
| Не знаете инструмент из вакансии | «Не работал» и пауза | «С Playwright не работал, писал на Selenium, логика ожиданий и локаторов похожа» |
| Спросили о пропущенном баге | Винить разработку или сроки | Что пропустили, почему, что изменили в проверках |
| Интервьюер не согласен с вашей оценкой бага | Защищаться до последнего | Уточнить его аргумент, обсудить влияние на пользователя |
Что делать, если не знаете ответа
Не изображайте знание — второй уточняющий вопрос это вскроет. Скажите честно и оттолкнитесь от похожего опыта: «Нагрузочное тестирование не проводил, но начал бы с вопроса, какую нагрузку ожидаем и какие показатели считаем приемлемыми».
Как справиться с волнением
Попросите полминуты подумать — это нормально. Запишите условие задачи и план ответа, прежде чем говорить. На практической части проговаривайте проверки вслух, по группам. И репетируйте заранее.
Как говорить о зарплате на собеседовании QA-инженера
Цифру обычно спрашивают на скрининге. Называйте диапазон и привязывайте его к задачам: «Ориентируюсь на диапазон от … до … на руки, уточню, когда пойму объём автоматизации и ответственность за релизы». Нижняя граница — сумма, ниже которой вы не перейдёте. Если вилки нет, спросите о бюджете позиции. Не занижайте ожидания из страха отказа: торговаться вверх потом сложнее.
Ориентиры — медианы зарплат в вакансиях QA-инженера на РаботаМакс на 21 октября 2026 года: стажёр — 82 000 ₽, junior — 90 000 ₽, middle — 100 000 ₽, senior — 250 000 ₽. В Москве медиана — 120 000 ₽, в Санкт-Петербурге — 98 500 ₽, в других регионах — 81 000 ₽.
Кроме оклада обсудите премии, пересмотр зарплаты, формат работы и обучение. Подробно о вилках по грейдам и городам — в статье Сколько зарабатывает QA-инженер.
Какие вопросы задать работодателю на собеседовании QA-инженера
- Сколько тестировщиков в команде и на сколько разработчиков приходится один QA?
- Как устроен релизный цикл и кто принимает решение, что сборка готова к выкатке?
- Какая доля регресса автоматизирована и кто пишет и поддерживает автотесты?
- На каком этапе QA подключается к задаче: на обсуждении требований или после разработки?
- Какие метрики качества команда смотрит после релиза и кто за них отвечает?
- Что должен сделать человек на этой позиции за первые три месяца, чтобы вы считали найм удачным?
Частые ошибки на собеседовании QA-инженера
- Перечисление проверок без системы. Двадцать проверок подряд звучат как хаос. Исправление: группируйте — позитивные, негативные, граничные, интерфейс, безопасность.
- Нет уточняющих вопросов. Тестировщик, который не спросил о требованиях, на работе тоже не спросит. Начинайте с вопроса о пользователе и ожидаемом поведении.
- Определение без примера. «Регресс — это проверка, что ничего не сломалось» — пересказ учебника. К каждой теме держите случай из своего проекта.
- Пренебрежение технической частью. Ответ «SQL у нас писали разработчики» снижает оценку. Подтяните базовые запросы и Postman.
- Противопоставление ручного тестирования и автоматизации. Спор о том, что «ручное умирает» или «автотесты не нужны», выглядит незрело. Говорите о том, где какой подход уместен.
- Нет вопросов к компании. Это выглядит как безразличие к работе. Подготовьте три-четыре вопроса из списка выше.
Что делать после собеседования
В течение суток отправьте рекрутеру короткое сообщение: поблагодарите за встречу и упомяните одну деталь из разговора — например, задачу по автоматизации регресса, которую обсуждали.
В конце встречи спросите, когда ждать ответа и кто его сообщит. Если срок прошёл, напишите один раз и спокойно уточните статус. Пока ждёте, не останавливайте другие отклики.
При отказе поблагодарите и попросите обратную связь: часто называют конкретную тему, которой не хватило, — SQL, автотесты или тест-дизайн. Запишите вопросы, на которых споткнулись, разберите их и прогоните ещё раз до следующего интервью — так отказ превращается в план подготовки.
Часто задаваемые вопросы
Можно ли потренироваться перед собеседованием онлайн?
Да. На РаботаМакс есть пробное собеседование с Максом — ИИ-консультантом в чате. Напишите, к какой позиции и грейду готовитесь, и отвечайте как на интервью: Макс задаёт вопросы и даёт обратную связь на ответы.
Нужно ли QA-инженеру уметь программировать?
Для ручного тестирования код писать не обязательно, но техническая база нужна почти везде. В топе ключевых навыков вакансий QA-инженера на РаботаМакс Python указан в 63 вакансиях, Java — в 44 (срез 21.10.2026).
Что спрашивают на собеседовании junior QA-инженера?
Виды тестирования, классы эквивалентности и граничные значения, оформление баг-репорта, разницу между серьёзностью и приоритетом, простой SQL и коды ответов HTTP. Часто просят протестировать форму вживую.
Какой язык выбрать для автотестов: Python или Java?
Смотрите на вакансии, которые вам интересны, и на язык разработки в команде. В срезе вакансий QA-инженера на РаботаМакс Python упомянут чаще Java: 63 против 44 (21.10.2026).
Нужно ли знать SQL тестировщику?
Да. SQL — самый частый ключевой навык в вакансиях QA-инженера на РаботаМакс: 101 упоминание (срез 21.10.2026). На собеседовании обычно хватает уверенных SELECT, JOIN, GROUP BY и HAVING.
Что важнее для работодателя: опыт или сертификаты?
Чаще смотрят на практику: баг-репорты, тест-кейсы, коллекции Postman и проект с автотестами, которые можно открыть и обсудить.