Вопросы на собеседовании QA-инженера — часть 2/3: Middle с разбором ответов

Это часть 2 из 3. ← Часть 1: Junior | Часть 3: Senior →

TL;DR: 9 вопросов для Middle QA: API-тестирование, автоматизация, CI/CD, SQL, контрактное тестирование и тест-дизайн. Разбор ответов с кодом и типичными ошибками.

Как пользоваться: Открой перед собеседованием → найди вопросы, в которых не уверен → разбери ответ и follow-up. Если можешь объяснить «почему», а не только «что» — ты готов.

Это вторая часть серии о вопросах на собеседованиях QA-инженеров. В первой части мы разобрали базу — теорию, документацию, тест-дизайн. Здесь — то, что спрашивают у Middle: инструменты, архитектура, работа с API и базами данных.

Middle QA — это уже не просто «ловец багов». По данным собеседований 2024–2026 (Habr, Glassdoor, профильные сообщества), от мидла ждут понимания архитектуры, умения автоматизировать и способности самостоятельно выстраивать стратегию тестирования.

Содержание

Middle

• 1. Что такое REST API и как его тестировать?
• 2. Чем PUT отличается от PATCH?
• 3. Что такое контрактное тестирование?
• 4. Как устроен CI/CD-пайплайн и где в нём место тестам?
• 5. Что такое Page Object и зачем он нужен?
• 6. Когда применять технику Pairwise?
• 7. SQL: чем DROP отличается от TRUNCATE?
• 8. Как перехватить и проанализировать HTTP-трафик?
• 9. Разработчик не согласен с вашим багом. Что делать?

1. Что такое REST API и как его тестировать?

Интервьюер проверяет: умеешь ли ты тестировать за пределами UI, на уровне сервера.

Как ответить:

REST (Representational State Transfer) — архитектурный стиль для взаимодействия клиента и сервера через HTTP. Основные методы: GET (получить), POST (создать), PUT (заменить), PATCH (обновить частично), DELETE (удалить).

Что проверять при тестировании API:

• Статус-коды — 200, 201, 400, 401, 403, 404, 500. Каждый должен возвращаться в правильной ситуации
• Тело ответа — структура JSON, типы данных, обязательные поля
• Валидация входных данных — пустые поля, неверные типы, граничные значения
• Аутентификация — запросы без токена, с истёкшим токеном, с чужим токеном
• Идемпотентность — повторный PUT с теми же данными не должен менять результат

Инструменты: Postman (ручное), RestAssured/Supertest (автоматизация), curl (быстрые проверки).

# Пример: проверка создания пользователя
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Test", "email": "test@example.com"}'
# Ожидаем: 201 Created + JSON с id нового пользователя

Типичная ошибка: Тестировать только happy path (200 OK). Интервьюер хочет услышать про негативные сценарии и edge cases.

Follow-up: Как протестировать API, если документации нет?

2. Чем PUT отличается от PATCH?

Интервьюер проверяет: понимаешь ли ты HTTP-семантику, а не просто «отправляю запросы».

Как ответить:

• PUT — полная замена ресурса. Отправляешь все поля, даже те, которые не менял. Если пропустил поле — оно обнулится.
• PATCH — частичное обновление. Отправляешь только изменённые поля.

// Текущий ресурс
{"id": 1, "name": "Иван", "email": "ivan@test.com", "role": "qa"}

// PUT /users/1 — заменяет полностью
{"id": 1, "name": "Иван", "email": "ivan@new.com", "role": "qa"}
// Если не передать role — может стать null

// PATCH /users/1 — обновляет частично
{"email": "ivan@new.com"}
// Остальные поля не тронуты

Типичная ошибка: Говорить «PUT обновляет, PATCH тоже обновляет, разницы нет». Разница принципиальная — и это частый баг, когда бэкенд неправильно реализует один из методов.

Follow-up: PUT должен быть идемпотентным. А PATCH? Почему?

3. Что такое контрактное тестирование?

Интервьюер проверяет: понимаешь ли ты, как тестировать микросервисы без полной интеграции.

Как ответить:

Контрактное тестирование — проверка того, что два сервиса (Consumer и Provider) согласны в формате данных, которыми обмениваются. Вместо поднятия обоих сервисов вместе, каждый проверяется отдельно по «контракту» — JSON-схеме ожидаемого взаимодействия.

Зачем: в системе из 20+ микросервисов интеграционные тесты нестабильны и дороги. Контрактные тесты быстрее, надёжнее и точно указывают, кто сломал совместимость.

Инструменты: Pact (самый популярный), Spring Cloud Contract.

Типичная ошибка: Путать с интеграционным тестированием. Контрактное не поднимает оба сервиса — оно проверяет формат обмена данными, а не бизнес-логику.

Follow-up: Кто пишет контракт — Consumer или Provider? Почему?

Мы разобрали работу с API и микросервисами. Дальше — инструменты и процессы: CI/CD, автоматизация, SQL.

4. Как устроен CI/CD-пайплайн и где в нём место тестам?

Интервьюер проверяет: понимаешь ли ты, как тесты встраиваются в процесс доставки, а не живут отдельно.

Как ответить:

Типичный пайплайн:

1. Commit → разработчик пушит код
2. Build → сборка проекта
3. Unit Tests → быстрые, запускаются первыми, при падении — сборка останавливается
4. Integration Tests → проверка взаимодействия компонентов
5. Deploy to Stage → деплой на тестовое окружение
6. E2E / Smoke Tests → проверка критических сценариев на stage
7. Deploy to Production → деплой на прод
8. Post-deploy Smoke → быстрая проверка, что прод жив

Главный принцип: быстрые тесты — раньше, медленные — позже. Если unit-тесты не прошли, нет смысла запускать E2E.

Инструменты: Jenkins, GitLab CI, GitHub Actions.

Типичная ошибка: Не знать, на каком этапе запускаются какие тесты. Или говорить «все тесты запускаются после деплоя».

Follow-up: Что делать, если E2E-тесты нестабильны и часто падают без реальных багов (flaky tests)?

5. Что такое Page Object и зачем он нужен?

Интервьюер проверяет: пишешь ли ты автотесты, которые можно поддерживать, или одноразовые скрипты.

Как ответить:

Page Object — паттерн проектирования автотестов, где каждая страница (или компонент) приложения представлена отдельным классом. Элементы и действия инкапсулированы в этом классе, а тесты вызывают методы, а не работают с локаторами напрямую.

# Без Page Object — хрупкий тест
def test_login():
    driver.find_element(By.ID, "email").send_keys("test@mail.com")
    driver.find_element(By.ID, "password").send_keys("123456")
    driver.find_element(By.CSS_SELECTOR, ".btn-submit").click()

# С Page Object — поддерживаемый тест
def test_login():
    login_page = LoginPage(driver)
    login_page.login("test@mail.com", "123456")
    assert login_page.is_logged_in()

Зачем: если UI изменился — правишь один класс, а не 50 тестов. Тесты читаемые, DRY, легко расширяемые.

Типичная ошибка: Знать определение, но не уметь объяснить выгоду. Интервьюер хочет услышать про maintainability и DRY.

Follow-up: Чем Page Object отличается от Page Factory? Когда что использовать?

6. Когда применять технику Pairwise?

Интервьюер проверяет: умеешь ли ты оптимизировать количество тестов без потери покрытия.

Как ответить:

Pairwise (попарное тестирование) — техника, которая сокращает количество тест-кейсов при множестве параметров. Вместо проверки всех комбинаций (которых может быть тысячи) покрываем все пары значений.

Пример: форма с 3 полями по 3 значения каждое:

• Браузер: Chrome, Firefox, Safari
• ОС: Windows, macOS, Linux
• Язык: RU, EN, DE

Все комбинации: 3 × 3 × 3 = 27. Pairwise: 9 тест-кейсов, покрывающих все пары.

Когда использовать:

• Много параметров с несколькими значениями
• Полное покрытие невозможно по времени
• Баги чаще возникают от взаимодействия двух факторов, а не трёх+

Инструменты: PICT (Microsoft), AllPairs, онлайн-генераторы.

Типичная ошибка: Использовать Pairwise для 2–3 параметров — там проще перебрать все комбинации. Pairwise эффективен при 4+ параметрах.

Follow-up: Какой процент дефектов, по статистике, вызван взаимодействием ровно двух факторов?

Инструменты и методологии разобрали. Теперь — работа с данными и soft skills.

7. SQL: чем DROP отличается от TRUNCATE?

Интервьюер проверяет: работаешь ли ты с базой данных и понимаешь ли последствия своих действий.

Как ответить:

• DROP TABLE — удаляет таблицу полностью: структуру, данные, индексы, всё. Таблица перестаёт существовать.
• TRUNCATE TABLE — удаляет все строки, но структура таблицы остаётся. Быстрее DELETE, потому что не логирует удаление каждой строки.
• DELETE — удаляет строки по условию (WHERE), можно откатить транзакцией.

-- Удалить всё и саму таблицу
DROP TABLE users;

-- Очистить данные, оставить структуру
TRUNCATE TABLE users;

-- Удалить конкретные строки
DELETE FROM users WHERE role = 'test';

Что важно для QA: при подготовке тестовых данных часто нужно очищать таблицы. TRUNCATE быстрее DELETE, но сбрасывает автоинкремент. DROP — когда пересоздаёшь схему.

Типичная ошибка: Не знать разницу или не упомянуть DELETE. Интервьюер обычно ожидает сравнение всех трёх.

Follow-up: Можно ли откатить TRUNCATE через ROLLBACK? А DROP?

8. Как перехватить и проанализировать HTTP-трафик?

Интервьюер проверяет: умеешь ли ты дебажить проблемы на уровне сети, а не только в UI.

Как ответить:

Инструменты:

• DevTools (Network tab) — встроен в браузер, видно все запросы, заголовки, тело, тайминги. Первый инструмент для веб.
• Charles Proxy / Fiddler — прокси для перехвата трафика десктопных и мобильных приложений. Позволяют модифицировать запросы и ответы.
• Burp Suite — продвинутый инструмент для security-тестирования, перехватывает и изменяет HTTPS-трафик.
• Wireshark — низкоуровневый анализ пакетов, полезен для сетевых проблем.

Для мобильного трафика: настраиваешь прокси на устройстве, устанавливаешь SSL-сертификат для расшифровки HTTPS.

Когда полезно: баг на фронте, но нужно понять — проблема в запросе клиента или ответе сервера? Смотришь трафик и точно знаешь.

Типичная ошибка: Знать только DevTools. Мидл должен уметь работать хотя бы с одним прокси-инструментом.

Follow-up: Как перехватить HTTPS-трафик мобильного приложения, которое использует certificate pinning?

9. Разработчик не согласен с вашим багом. Что делать?

Интервьюер проверяет: умеешь ли ты отстаивать качество без конфликтов.

Как ответить:

1. Перепроверить — убедиться, что баг реален. Воспроизвести ещё раз, на другом окружении.
2. Ссылаться на артефакты — требования, макеты, user stories. «По спецификации X ожидается Y, а происходит Z».
3. Обсудить спокойно — возможно, это фича, а не баг. Или требования устарели.
4. Привлечь третью сторону — если не получается договориться, подключить PM или тех-лида. Не для «наказания», а для принятия решения.

Никогда: не переходить на личности, не закрывать баг без решения, не эскалировать сразу.

Типичная ошибка: Говорить «эскалирую руководству» как первый шаг. Интервьюер хочет услышать про зрелый подход — диалог, аргументы, данные.

Follow-up: Разработчик говорит «it works on my machine». Ваши действия?

Итого Middle: 9 вопросов. Фокус — API, автоматизация, CI/CD, SQL и коммуникация. От мидла ждут не только знания инструментов, но и понимания, зачем и когда их применять.

Как готовиться

• API: Postman Learning Center — бесплатные курсы. Потренируйся на открытых API (JSONPlaceholder, ReqRes)
• Автоматизация: Напиши 10 автотестов с Page Object на любом сайте. Selenium + Python или Playwright — оба варианта котируются
• SQL: Решай задачи на sql-ex.ru или HackerRank SQL — 20–30 задач закроют 80% вопросов
• CI/CD: Настрой GitHub Actions для pet-проекта — запуск тестов на push
• Время на подготовку: 2–4 недели при ежедневных занятиях по 1–2 часа

Чего НЕ спрашивают

• Синтаксис конкретного фреймворка наизусть — можно подсмотреть в документации, важнее понимать принципы
• Детали настройки Jenkins — от мидла не ждут DevOps-экспертизу, достаточно понимать пайплайн
• Ручное тестирование базовых сценариев — это уровень Junior, к Middle уже должны быть навыки автоматизации

Как попробовать Sobes AI

Sobes AI — AI-ассистент для технических собеседований в реальном времени.

1. Зайди на sobesai.app и скачай приложение
2. Запусти перед собеседованием или тренировкой
3. AI слушает вопросы и подсказывает структурированные ответы
4. Потренируй ответы на вопросы про API, SQL и автоматизацию с обратной связью

Это часть 2 из 3. ← Часть 1: Junior | Часть 3: Senior →