Собеседование QA в 2026-м редко проваливается из-за «не назвал все виды тестирования из учебника». Чаще ломается другое: человек говорит «я внимательный», но не может спроектировать проверку формы заказа, описать баг так, чтобы разработка не переспрашивала, и отличить дефект от пожелания. Нанимающий покупает вероятность, что релиз не уедет с дырой, которую вы уже видели и не зафиксировали.

Ниже — блоки скрининга и техэкрана, полные ответы и SQL/API на том уровне, который реально ставят ручному и mixed-слоту. Общий каркас — вопросы на собеседовании. Карта навыков без культа инструментов — в что должен знать QA. Смотреть слоты: вакансии QA.

Коротко:

  • Тест-дизайн важнее списка терминов: эквивалентность, границы, негатив, один проход «что сломает деньги / данные / доступ».
  • Баг-репорт — шаги, ожидание, факт, окружение, вложения. Не роман.
  • SQL и API спрашивают как чтение и проверку, не как разработку сервиса.
  • Код на ручном слоте — плюс, не обязательный вход, пока в вакансии нет automation.
  • Готовьте 1–2 своих контура: регресс, приёмка, инцидент «пропустили на прод».

Как читать вакансию, чтобы не готовить SDET вчера

Выпишите: ручной / automation / mixed, веб / API / мобайл, SQL, английские отчёты, дежурства, релизы. Если в тексте чек-листы и баг-репорты — готовьте дизайн и документацию. Если Pytest и CI — готовьте код и пайплайн, иначе вас услышат не на ту роль. Не называйте себя automation в резюме, если автотестов нет: на экране это вскроется за десять минут. Как честно описать контур — в резюме QA.

Junior: сценарии, баги, базовый HTTP, простой SELECT. Middle: риски релиза, данные, API-контракт, приоритезация. Senior: процесс, метрики качества, спор с разработкой и продуктом. Не готовьте «стратегию QA отдела» на junior-слот.

На скрининге с рекрутером не читайте классификацию видов тестирования. Назовите контур: веб-кабинет, регресс, отчёты, SQL на чтение. Вилку и пояс — как на любом HR-экране. Технику оставьте инженеру. Если рекрутер спрашивает «автоматизируете?» — честная граница: «пишу API-проверки / только руками / вот пайплайн». Выдуманный Selenium на этом же звонке потом придётся защищать кодом.

Тест-дизайн: экран, который можно открыть

Типовая формулировка: «есть форма оформления заказа: телефон, адрес, способ оплаты. Что будете проверять?»

Сначала цель: заказ создаётся, деньги не списываются дважды, пользователь видит понятный статус. Позитив: валидный телефон и адрес, один способ оплаты, успешный ответ сервера, заказ в списке. Границы телефона: пусто, слишком короткий, буквы, валидный с плюсом и без. Адрес: пусто, очень длинная строка, спецсимволы, которые ломают подсказку.

Негатив: ушёл со страницы посреди ввода — поля не должны исчезнуть без предупреждения, если так задумано сохранить черновик. Двойной клик «оплатить»: не должно быть двух заказов. Сеть: 500 и таймаут — сообщение, данные формы на месте. Права: чужой заказ по прямой ссылке не открывается.

Приоритет: сначала деньги и дубль, потом валидация, потом косметика кнопки. Чек-лист на регресс — не 80 строк «проверить всё», а критичный путь плюс то, что уже ломалось. Если время короткое, режу косметику и оставляю дубль, оплату и доступ.

После такого ответа копать будут в приоритет и в «а если промокод». К этому готовьте одну ветку, не вторую энциклопедию.

Баг-репорт, который не возвращают

Спросят: «опишите баг». Не «кнопка не работает».

Заголовок: двойной клик на «оплатить» создаёт два заказа с одной картой, статус оба «оплачен». Окружение: Chrome актуальный, стейдж, учётка тестового покупателя, заказ на 1 позицию. Шаги: открыть чекаут, заполнить валидные данные, дважды быстро нажать «оплатить», не ждать спиннер. Ожидание: один заказ, кнопка неактивна на время запроса. Факт: два id в списке заказов, два списания в тестовом шлюзе. Вложения: скрин списка, id заказов, время, ролик 15 секунд. Серьёзность: критический, деньги. Воспроизводится стабильно на стейдже, на проде не проверяла без разрешения.

Это закрывает вопрос лучше, чем «я умею писать подробные баги». Follow-up: severity vs priority, когда не баг, а enhancement, когда эскалация «на проде сейчас».

SQL на QA-экране

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

Проверить, что после оформления есть ровно один заказ:

SELECT id, user_id, status, amount, created_at FROM orders WHERE user_id = 1042 AND created_at >= '2026-08-29 12:00:00' ORDER BY created_at DESC;

Если в UI один заказ, а строк две с разницей в секунду — это тот самый двойной submit. Джойн на позиции, только если проверяю состав:

SELECT o.id, COUNT(i.id) AS items FROM orders o JOIN order_items i ON i.order_id = o.id WHERE o.id = 90011 GROUP BY o.id;

EXPLAIN на этом слоте мне нужен, если скажете «отчёт регресса тормозит». Иначе достаточно читать таблицу и не обновлять прод-данные руками без договорённости.

Не выдумывайте админский DROP. На интервью это не смешно. Права на чтение и тестовый контур — часть ответа про зрелость.

API: контракт, не Postman как религия

Спросят: чем 200 с ошибкой в теле отличается от 422, что такое идемпотентность на повтор POST, как проверить, что заголовок авторизации обязателен. Ответ опирайте на сценарий заказа, не на список кодов из шпаргалки.

Создать заказ: POST /orders, тело с позициями. Ожидаю 201 и id. Повтор с тем же Idempotency-Key — тот же id, не второй заказ. Без ключа — риск дубля, это и заведу как риск, если в контракте ключа нет. 422 — валидация, тело можно разобрать в UI. 401 — без токена, не должен пройти. 500 — не маскирую под «нет заказов»: в UI это ошибка сервера, в отчёте — отдельно от пустого списка.

Проверяю контракт по полям, которые рисует кабинет, не по всему swagger целиком. Если поле status приехало unknown — это баг контракта, не «ну подождём». Автотест на API ставлю на критичный путь, UI — на то, что глазами быстрее поймать вёрстку и фокус.

Когда спросят код

На ручном слоте могут попросить прочитать кусок теста или написать проверку статуса. Не паникуйте. Покажите, что понимаете assert, setup, почему флаки плохи. На automation-слоте без кода вы не пройдёте — тогда готовьте свой пайплайн, не «смотрел курс Selenium». Если кода нет, а вакансия mixed — честно: «пишу SQL и API, UI-автотесты — следующий шаг, в резюме не рисовал». Честная граница сильнее выдуманного SDET.

Спор с разработкой — отдельный вопрос. «Баг не баг» решаете фактом: шаги, ожидание из требования или здравый смысл денег, не характером. Если требования дырявые — фиксируете вопрос до релиза, не после прод-инцидента. Эскалация: сначала разработчик, потом лид, не общий чат с сарказмом. Это тот же тон, что в письме: граница без сцены.

История про пропущенный баг

Спросят. Готовьте STAR без самобичевания на три минуты.

Ситуация: на проде после акции два заказа с одним промокодом, который должен был сгореть. Задача была проверить акцию на счастливом пути. Я прогнала позитив и границы суммы, повторное применение с другой учётки — нет. Результат: дыра на проде, поддержка, хотфикс. Почему: не было кейса «тот же пользователь, второй заказ сразу». Что сделала: добавила в регресс, запросила фикстуру «промокод уже использован», написала в шаблоне приёмки явный пункт. Что не делаю: не прячу это как «продукт виноват». Моя дыра в покрытии, даже если требования были дырявые — я могла задать вопрос до релиза.

Это сильнее «я перфекционист». Behavioral на QA — про эскалацию и границы, не про характер.

Смоук, регресс, оценка времени

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

Оценка тестового покрытия на интервью: «сколько времени на вот эту форму». Скажите диапазон и что режете, если времени меньше. «Сколько надо» без цифры — тот же антипаттерн, что на неоплаченном тесте. Заложите время на данные: без фикстуры «промокод уже использован» вы не проверите акцию, сколько ни сидите в UI.

На приёмку формы заказа при нормальных фикстурах закладываю 2–3 часа: позитив, дубль, два кода ошибок API, права на чужой заказ, пустой список после фильтра. Если фикстур нет и надо руками копить состояние — это уже полдня, и я это скажу до старта, не после. В два часа до релиза оставлю дубль, оплату и вход, косметику и редкий браузер вынесу. Напишу в тикете, что не покрыто — чтобы это был риск продукта, не молчаливая дыра.

Неделя подготовки

  1. Один свой продукт или учебный сервис: критичный путь, 10 кейсов, 3 баг-репорта в шаблоне.
  2. SQL: SELECT, JOIN, WHERE по дате. Два запроса по своей предметке.
  3. API: один POST и один GET, коды, повтор.
  4. Вслух: форма заказа и история про прод. Диктофон. Живой прогон — подготовка к интервью.

Частые вопросы

Нужно ли зубрить ISTQB формулировки?

Термины полезны, если вы ими пользуетесь. Заучивание «что такое верификация» без экрана не спасает. На CIS-рынке чаще просят сделать, чем процитировать стандарт.

Спросят ли теорию про виды тестирования?

Коротко да: регресс vs смоук, функционал vs нефункционал одной фразой с примером. Не десять минут классификаций.

Что, если нет коммерческого стажа?

Несите папку с кейсами и багами. Письмо без извинения — в сопроводительном без опыта. Экран тот же: дизайн и отчёт, не трудовая.

Обязателен ли английский отчёт?

Если вакансия на английском — да, шаблон шагов. Если русскоязычная команда — на языке команды. Не смешивайте для солидности.

Как отказаться от огромного тестового на 40 кейсов за ночь?

Лимит часов и урезанный скоуп — в отказе от тестового. На QA часто просят «протестируйте наш прод» — это красный флаг, не честь.

Нужно ли сопроводительное?

Короткое, с ссылкой на папку отчётов. Шаблон: генератор и короткое письмо.

Что сделать сейчас

Возьмите один экран (заказ, тикет, форма). Напишите 8 кейсов и один полный баг-репорт. Напишите два SELECT под этот экран. Проговорите ответ про форму вслух за три минуты. Затем откликайтесь на QA-вакансии с этим артефактом, а не с фразой «внимательный и ответственный».

Если завтра уже экран, не зубрите ISTQB ночью. Возьмите свой продукт, выпишите критичный путь денег и один прод-баг или учебный баг в STAR. Этого хватает, чтобы не звучать пустым. Остальное — follow-up по их стеку: API, SQL, смена, английский отчёт. Каркас один, факты ваши.