Когда идёшь на позицию ручного QA с опытом, недостаточно повторить определения из учебника. Интервьюеру важно понять, как ты рассуждаешь и применяешь знания в реальной работе.

Мой главный лайфхак: готовить не только теорию, но и короткие примеры из своих проектов 💜

🔹 «Как вы тестируете новую задачу?»

Можно ответить так:

«Сначала изучаю требования и уточняю спорные моменты. Определяю затронутые компоненты и риски. Затем составляю проверки, подготавливаю данные, тестирую позитивные и негативные сценарии. После исправлений провожу ретест и оцениваю необходимый регресс».

🔹 «В чём разница между smoke, regression и retest?»

«Smoke проверяет, что основные функции системы работают и сборку вообще можно тестировать. Retest подтверждает исправление конкретного дефекта. Regression помогает убедиться, что изменения не сломали ранее работавший функционал».

🔹 «Как вы тестируете API?»

«Проверяю метод, URL, заголовки, параметры, тело запроса, статус и структуру ответа. Тестирую обязательные поля, типы данных, граничные значения, авторизацию и обработку ошибок. Для интеграций дополнительно проверяю, дошло ли сообщение до очереди, сохранились ли данные в БД и появились ли нужные записи в логах».

🔹 «Какие SQL-запросы вы умеете писать?»

Не стоит отвечать просто: «Знаю SQL».

Лучше конкретно:

«Использую SELECT, WHERE, JOIN, GROUP BY, ORDER BY, агрегатные функции и подзапросы. Например, могу найти пользователей, у которых нет заказов»:

SELECT u.id, u.name FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE o.id IS NULL;

Здесь полезно сразу объяснить: LEFT JOIN оставляет всех пользователей, а условие o.id IS NULL показывает тех, для кого связанный заказ не найден.

🔹 «Что такое JOIN и какие виды вы знаете?»

«INNER JOIN возвращает только совпадающие записи из двух таблиц. LEFT JOIN возвращает все записи из левой таблицы и совпадения из правой. Если совпадения нет, поля правой таблицы будут NULL».

🔹 «Зачем ручному тестировщику знать ООП?»

Даже на Manual QA могут проверить базовое понимание.

Простой ответ:

«ООП — подход, при котором программа строится из объектов, содержащих данные и поведение. Основные принципы: инкапсуляция, наследование, полиморфизм и абстракция».

Но лучше добавить пример:

«Например, есть базовый класс “Пользователь”, а от него наследуются “Администратор” и “Клиент”. У них есть общие поля, но разные права и поведение. Для тестировщика это помогает понимать структуру приложения и заранее выделять проверки ролей и доступов».

🔹 «Расскажите о сложном баге»

Здесь хорошо работает схема:

✨ что произошло; ✨ как обнаружили; ✨ как локализовали; ✨ в чём оказалась причина; ✨ какой был результат.

Например:

«Ответ API был успешным, но данные не появлялись в конечной системе. Я проверила запрос, логи сервисов и сообщения в брокере. Выяснилось, что нужный заголовок передавался в первую очередь, но терялся на следующем этапе интеграции. Я описала точку потери и приложила подтверждения из логов и очередей».

Ещё могут спросить:

🔸 как отличить баг от особенности; 🔸 что делать с неполными требованиями; 🔸 как выбрать регресс при нехватке времени; 🔸 что проверять в DevTools; 🔸 какие бывают HTTP-методы и статусы; 🔸 как тестировать форму, авторизацию или загрузку файла; 🔸 что делать, если разработчик не согласен с дефектом.

Главное на собеседовании с опытом: не пытаться вспомнить идеальную формулировку.

Лучше сказать своими словами, привести рабочий пример и показать ход мыслей. Потому что сильный QA не только знает термины, но и умеет задавать вопросы, оценивать риски и искать причину проблемы 🔍

А какой вопрос на техническом собеседовании однажды поставил вас в тупик? 👀

#qaengineer #manualqa #тестировщик #собеседование #поискработы #sql #api #карьера