Собеседование на QA в 2026: как готовиться и что реально спрашивают

Собеседование на QA проверяет не столько объём знаний, сколько как ты думаешь: умеешь ли структурно разложить задачу, отличить severity от priority, объяснить решение и поспорить без агрессии. Ниже — карта подготовки: что спрашивают по секциям и как отвечать, чтобы выделиться.

Из чего обычно состоит собес

Теория тестирования (виды, уровни, техники тест-дизайна).
Практика: «протестируй X» и/или написать тест-кейсы/баг-репорт.
API / SQL — базовый уровень почти везде.
Автоматизация — если позиция QAA (локаторы, ожидания, flaky, архитектура).
Поведенческое: конфликты, приоритизация, работа с командой.
Ваши вопросы к компании (да, это оценивают).

Теория: что реально спрашивают

Техники тест-дизайна: классы эквивалентности, граничные значения, таблицы решений, pairwise, переходы состояний. Не определения ради определений — умение применить.
Severity vs Priority: severity — насколько серьёзно ломает (техническая тяжесть), priority — насколько срочно чинить (бизнес). Классика: опечатка в логотипе на главной = низкая severity, высокая priority.
Уровни и виды: unit/integration/e2e; smoke/regression/sanity; функциональное vs нефункциональное.
Пирамида/Trophy: где должно быть больше тестов и почему (быстрые и дешёвые — ниже).
База терминологии — по ISTQB Foundation (даже если не сдаёшь сертификат, словарь общий).

«Протестируй X»: фреймворк, а не поток кейсов

Главная ошибка — сыпать случайные кейсы. Интервьюер хочет увидеть структуру. Сначала задайте уточняющие вопросы (что за продукт, кто пользователь, какие требования), затем идите по осям:

Функциональность: основной happy path — работает ли по назначению.
Данные и границы: пусто, минимум/максимум, за пределом, спецсимволы, формат.
Негатив: неверный ввод, ошибки, отказы — понятная реакция.
Нефункционалка: производительность, безопасность, доступность, локализация.
Окружение/совместимость: устройства, ОС, браузеры, сеть, ориентация.
Интеграции и состояния: зависимые системы, прерывания, восстановление.

Пример «протестируй форму логина»: happy path → пустые поля, граничная длина, неверный пароль, блокировка после N попыток, SQL/XSS в полях, вставка пароля, показать/скрыть, забыли пароль, сессия, медленная сеть, разные браузеры, screen reader. Видно мышление, а не зубрёжку.

Баг-репорт на интервью

Если просят оформить баг — дайте воспроизводимую структуру: заголовок (кратко суть), окружение, шаги, фактический результат vs ожидаемый, вложения (лог/скрин), severity и priority. Главное — чтобы по репорту баг можно было воспроизвести без вас.

API и SQL — минимум, который спрашивают

API: методы (GET/POST/PUT/PATCH/DELETE), коды ответов (2xx/4xx/5xx, разница 401 vs 403), идемпотентность, статус vs тело, как тестировать REST (позитив/негатив/границы/авторизация).
SQL: SELECT с WHERE, JOIN (inner/left), GROUP BY/COUNT, простые подзапросы. Часто валятся на JOIN и на «выбери дубли».

Автоматизация (для QAA)

Локаторы: почему устойчивые (data-testid/role) лучше хрупких XPath по индексам.
Ожидания: explicit/auto-wait вместо sleep; почему sleep — источник flaky.
Flaky-тесты: причины (тайминги, общие данные, изоляция) и борьба.
Архитектура: Page Object и зачем; где провести границу слоёв.
Что автоматизировать, а что нет (ROI, стабильность, пирамида).

Поведенческие: отвечайте по STAR

Структура STAR (Situation — Task — Action — Result) превращает «ну, был случай…» в внятную историю. Частые вопросы:

Конфликт с разработчиком («это не баг, это фича») — как договорились.
Релиз ушёл с багом — что сделали и какие выводы (без перекладывания вины).
Как приоритизируете при нехватке времени (risk-based).
Как сообщали плохие новости стейкхолдерам (problem + options + recommendation).
Расскажите про самый сложный баг — что и как нашли.

Готовьте 4–5 реальных историй заранее и переиспользуйте под разные вопросы.

Ваши вопросы к компании (и красные флаги)

В конце почти всегда «какие вопросы?». Молчание = минус. Спросите про процессы и культуру качества:

Как устроен релиз-цикл и кто отвечает за качество? Есть ли автоматизация и CI?
Как заводятся и приоритизируются баги? Есть ли quality-метрики?
Как QA участвует на ранних этапах (требования, дизайн)?
Красные флаги: «QA должен ловить все баги», нет процесса, ручной деплой в пятницу вечером, тестировщик = единственный гейт качества, овертаймы как норма.

Подготовка: за неделю и за день

За неделю

Повторить техники тест-дизайна и severity/priority на примерах.
Прорешать 5–10 SQL-задач (JOIN, GROUP BY) и потыкать API в Postman/Bruno.
Подготовить 4–5 STAR-историй; проговорить вслух.
Прогнать 2–3 «протестируй X» по фреймворку (форма, лифт, корзина).
Изучить продукт компании — потестируйте его и придите с наблюдениями.

За день

Перечитать свой фреймворк ответа на «протестируй X».
Подготовить вопросы к команде.
Проверить технику для онлайна (камера, шаринг экрана, среда для кодинга).
Выспаться — это реально влияет на структурность ответов.

Чек-лист подготовки (10 пунктов)

Знаю техники тест-дизайна и применяю, а не пересказываю.
Чётко объясняю severity vs priority на примере.
Есть фреймворк ответа на «протестируй X» (оси, а не поток кейсов).
Умею оформить воспроизводимый баг-репорт.
API: коды ответов, методы, как тестировать REST.
SQL: SELECT/WHERE/JOIN/GROUP BY уверенно.
Для QAA: локаторы, ожидания, flaky, Page Object.
4–5 STAR-историй готовы и проговорены.
Есть 4–5 вопросов к компании; знаю красные флаги.
Изучил продукт компании и пришёл с наблюдениями.

Итог

Сильный кандидат отличается не количеством заученных определений, а структурой мышления: разложить «протестируй X» по осям, отделить severity от priority, рассказать историю по STAR и задать умные вопросы про процессы. Готовьтесь не «прочитать теорию», а проговорить вслух — собес это устный жанр.