Собеседование на тестировщика: вопросы по уровням и как отвечать

Три уровня вопросов

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

• Джун: терминология (виды и уровни тестирования), жизненный цикл бага, чек-лист против тест-кейса, умение найти ошибки в простой форме, базовые SQL и HTTP.
• Мидл: тест-дизайн по требованиям с нечёткими местами, приоритизация по рискам, API-тесты, участие в процессе (ретро, оценка, релиз), понимание автоматизации: что и зачем автоматизируют.
• QA Automation: всё выше плюс код (Python, Java или JS), фреймворки, устройство стабильного теста, работа с CI.

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

Теория и тест-дизайн: как отвечать на «базу»

«Чем отличаются классы эквивалентности и граничные значения?» Класс эквивалентности — группа входных данных, на которую система реагирует одинаково, поэтому проверяют по одному представителю из группы. Граничные значения — края этих групп. ISTQB определяет обе техники как техники тест-дизайна «чёрного ящика». Пример: поле принимает количество от 1 до 10. Классы: меньше 1, от 1 до 10, больше 10, не число. Границы: 0, 1, 10, 11.

«Smoke, sanity, регресс?» Smoke — быстрая проверка, что сборка вообще работоспособна. Sanity — узкая проверка конкретного исправления. Регресс — проверка, что изменения не сломали старое. Хороший ответ добавляет: регресс первым уходит в автоматизацию, потому что повторяется каждый релиз.

«Что такое severity и priority?» Severity — тяжесть последствий для системы, priority — срочность исправления для бизнеса. Опечатка в названии компании на главной: severity низкая, priority высокая.

«Как тестировать, если требований нет?» Не изобретать их молча: задать вопросы автору задачи, зафиксировать допущения письменно, затем идти от ожиданий пользователя и похожих функций продукта. Такой ответ показывает зрелость лучше, чем «буду тестировать по здравому смыслу».

Практика: баг-репорт и «найди ошибки» в форме

Частая задача — протестировать форму регистрации или поле на ходу. Не прыгайте сразу в «а что если ввести эмодзи». Сначала озвучьте план: сначала позитивный сценарий, затем обязательные поля, границы длины, формат (email, телефон), спецсимволы, повторная отправка, поведение при потере сети, доступность (Tab, Enter). Интервьюер оценивает системность.

Хороший баг-репорт — это:

• заголовок «что и где сломано» одной фразой;
• окружение: версия сборки, браузер или ОС, устройство;
• шаги воспроизведения, пронумерованные;
• фактический и ожидаемый результат;
• вложения: скриншот, видео, лог, запрос и ответ.

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

API, HTTP и SQL

Тестировщика почти всегда спрашивают про HTTP. По справочнику MDN: 2xx — запрос принят и выполнен, 3xx — клиенту нужно выполнить дополнительное действие (обычно перейти по другому адресу), 4xx — ошибка на стороне запроса, 5xx — сервер не справился с корректным запросом. Типичные уточнения:

• 401 против 403. 401 означает «не аутентифицирован» (несмотря на название Unauthorized), 403 — личность известна, но прав нет, и повторный вход не поможет.
• 201 и 204. 201 — ресурс создан (обычно после POST), 204 — успех без тела ответа.
• 429. Слишком много запросов за период (ограничение частоты).
• 500 и 502. 500 — общая ошибка сервера, 502 — шлюз или прокси получил неверный ответ от вышестоящего сервера.

Как проверять API в Postman. Во вкладке Scripts → Post-response пишут проверки через pm.test. Пример из документации: pm.test("Status test", function () { pm.response.to.have.status(200); });. Утверждения можно писать через pm.expect (Chai), а результаты смотреть на вкладке Test Results. Хороший ответ перечисляет, что проверять: код, тело, заголовки, время, поведение на ошибки.

SQL. Ожидайте простые задачи: выбрать записи с условием, соединить две таблицы (JOIN), посчитать COUNT с GROUP BY, найти дубли. Зачем тестировщику SQL: проверить, что данные после операции действительно сохранились правильно.

Автоматизация: что спрашивают у QA Automation

Как сделать UI-тест стабильным? В документации Playwright сказано приоритизировать атрибуты, видимые пользователю, и явные контракты, а не селекторы CSS или XPath, привязанные к структуре DOM; использовать проверки, которые ждут выполнения условия (expect), и учитывать, что у локаторов есть автоожидание и повторные попытки. Для Selenium важна другая оговорка из документации: неявные и явные ожидания не следует смешивать, иначе время ожидания становится непредсказуемым.

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

Что такое фикстуры и параметризация в pytest? Фикстура готовит то, что нужно тесту, и передаётся аргументом; область действия — function, class, module, package или session, а код очистки пишут после yield. Параметризация запускает один тест на нескольких наборах данных: в примере из документации @pytest.mark.parametrize("test_input,expected", [("3+5", 8), ("2+4", 6), ("6*9", 42)]) тест выполняется три раза, и упавший случай виден отдельно.

Что делать с нестабильным (flaky) тестом? Не лечить повторами «до зелёного». Найти причину: ожидания, зависимость от данных или порядка, нестабильное окружение. До исправления изолировать тест, чтобы он не маскировал настоящие падения.

Вопросы про процесс и поведение

• «Расскажите о самом интересном баге». Заранее подготовьте историю: как нашли, как локализовали, что изменилось после. Структуру подачи см. в ответе на «расскажите о себе».
• «С разработчиком спор: баг или фича?» Обратиться к требованиям; если они двусмысленны, вынести вопрос владельцу продукта.
• «Релиз завтра, времени мало». Приоритизация по рискам: оплата, вход, сохранение данных, изменённые в релизе места; честно сказать, что осталось непокрытым.
• «Почему QA?» Ответ про интерес к качеству и системному мышлению звучит лучше, чем «в IT платят».

План подготовки на неделю

1. Возьмите форму любого сайта и составьте для неё классы эквивалентности и границы.
2. Напишите три баг-репорта и перечитайте их глазами разработчика.
3. В Postman соберите коллекцию из 4–5 запросов к открытому API с pm.test на каждый.
4. Повторите SQL: JOIN, GROUP BY, поиск дублей.
5. Для автоматизации: три теста на Playwright или pytest, запустите по три раза подряд и устраните нестабильность.
6. Проговорите ответы вслух: техническую часть оценивают по ходу рассуждения.

Если волнуетесь или собеседование на английском

Часть QA-вакансий проходит на английском целиком или частично; термины (test case, flaky, regression) стоит заранее уметь произнести вслух. О том, как устроена подсказка в реальном времени, написано в статье об ИИ-помощнике на собеседовании. Если вам нужна подсказка по вопросу в реальном времени, есть Interview Copilot: оверлей слушает звук звонка и показывает подсказку; есть бесплатный план без карты. Про окно, которое не попадает в захват при демонстрации, читайте на странице невидимого помощника. Правила использования ИИ-подсказок определяет работодатель: перед живым собеседованием спросите рекрутёра, что разрешено, и не пользуйтесь инструментом, если это запрещено. Заменить ваше понимание он не может: уточняющие вопросы задают вам.

Источники

• ISTQB Glossary: equivalence partitioning, boundary value analysis, defect report
• Postman Docs: Test scripts
• MDN: HTTP response status codes
• Playwright: Best Practices
• Selenium: Waits
• pytest: Parametrizing tests и fixtures

Проверено 12.11.2026.

Как здесь помогает приложение

Похожие статьи

Читайте дальше