Собеседование 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 — на то, что глазами быстрее поймать вёрстку и фокус.