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

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

TL;DR: 8 вопросов для Senior QA: стратегия тестирования, метрики качества, нагрузочное тестирование, безопасность, AI-тестирование и управление рисками. Не про инструменты — про мышление.

Как пользоваться: Если ты претендуешь на Senior — пройдись по каждому вопросу и проверь, можешь ли ты не просто ответить, а аргументировать свою позицию с примерами из опыта.

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

По данным собеседований 2024–2026 (Habr, Glassdoor, ENIGMA AI), от Senior QA ждут не знания инструментов — а понимания, как выстроить процесс обеспечения качества, который масштабируется вместе с продуктом.

Содержание

Senior

• 1. Как выстроить стратегию тестирования для нового проекта?
• 2. Какие метрики качества вы использовали и зачем?
• 3. Shift-left testing — что это на практике?
• 4. Как спланировать нагрузочное тестирование?
• 5. OWASP Top 10 — что должен знать QA?
• 6. Как тестировать приложения с LLM/AI?
• 7. Root Cause Analysis — как проводить?
• 8. Продайте тестирование клиенту, который не хочет за него платить

1. Как выстроить стратегию тестирования для нового проекта?

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

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

Стратегия строится от рисков и бизнес-контекста, а не от инструментов:

1. Анализ продукта — архитектура (монолит/микросервисы), стек, критичные бизнес-процессы, SLA
2. Анализ рисков — что сломается дороже всего? Платёжная система важнее страницы «О нас»
3. Пирамида тестирования — определить соотношение: много unit-тестов, меньше интеграционных, минимум E2E
4. Автоматизация — что автоматизировать (регрессия, smoke), что оставить ручным (UX, exploratory)
5. Окружения — dev, stage, prod-like. Кто отвечает за каждое
6. Метрики — как будем измерять качество (покрытие, дефект-плотность, MTTR)
7. Процесс — на каком этапе SDLC подключается QA, Definition of Done

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

Follow-up: Как изменится стратегия при переходе с монолита на микросервисы?

2. Какие метрики качества вы использовали и зачем?

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

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

Метрики делятся на процессные и продуктовые:

Процессные (DORA metrics):

• Change Failure Rate — процент деплоев, приведших к инцидентам. QA напрямую влияет на эту метрику
• Mean Time to Recovery (MTTR) — среднее время восстановления после инцидента
• Time to Market (TTM) — время от задачи до продакшена. QA может быть бутылочным горлышком — или ускорителем

Продуктовые:

• Defect Density — количество дефектов на 1000 строк кода. Показывает качество кодовой базы
• Defect Removal Efficiency (DRE) — процент дефектов, найденных до продакшена. DRE 95% = из 100 багов 95 нашли до релиза
• Test Coverage — процент кода/требований, покрытых тестами. Не самоцель, но индикатор слепых зон

Главное: метрика без контекста бесполезна. Coverage 80% ничего не значит, если не покрыты критические пути.

Типичная ошибка: Перечислить метрики без объяснения, как ты их использовал для принятия решений. Метрики — инструмент управления, а не самоцель.

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

3. Shift-left testing — что это на практике?

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

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

Shift-left — смещение тестирования на ранние этапы разработки. Не лозунг, а конкретные практики:

• Ревью требований — QA читает User Story до разработки и находит неоднозначности. «А что если пользователь нажмёт Cancel во время оплаты?»
• Three Amigos — встреча QA + Dev + PO перед спринтом для разбора acceptance criteria
• Unit-тесты — QA помогает разработчикам писать тестируемый код, ревьюит unit-тесты
• Static Analysis — линтеры, SAST-инструменты запускаются до мержа в основную ветку
• API-тесты до UI — тестируем бэкенд, не дожидаясь фронтенда

Результат: дефект, найденный на этапе требований, стоит в 10–100 раз дешевле, чем найденный на продакшене (по данным IBM Systems Sciences Institute и NIST).

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

Follow-up: А что такое shift-right? Когда это нужно?

Разобрали стратегию и процессы. Дальше — технические вопросы уровня Senior: нагрузка, безопасность, AI.

4. Как спланировать нагрузочное тестирование?

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

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

План нагрузочного тестирования:

1. Определить цели — SLA: время отклика < 200ms при 1000 RPS, 99.9% uptime
2. Собрать профиль нагрузки — анализ production-логов: пиковые часы, типичные сценарии, распределение запросов по эндпоинтам
3. Выбрать сценарии — критические user flows: логин, поиск, оплата. Не все 500 эндпоинтов.
4. Подготовить данные — тестовые пользователи, товары, транзакции. Данные должны быть реалистичными по объёму
5. Настроить мониторинг — CPU, RAM, I/O, latency, error rate. Grafana + Prometheus — стандарт
6. Провести виды тестов:
   • Load — штатная нагрузка, проверяем SLA
   • Stress — превышаем лимиты, ищем точку отказа
   • Soak/Endurance — длительная нагрузка, ищем утечки памяти
   • Spike — резкий всплеск, проверяем восстановление

Инструменты: k6 (современный, скрипты на JS), Gatling (Scala), JMeter (классика, тяжеловесный).

// k6 — пример простого load-теста
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 100,        // 100 виртуальных пользователей
  duration: '5m',  // 5 минут
};

export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status 200': (r) => r.status === 200,
    'latency < 200ms': (r) => r.timings.duration < 200,
  });
}

Типичная ошибка: Запустить JMeter с 1000 потоков и сказать «система упала при 1000 пользователях». Без профиля нагрузки, мониторинга и анализа — это не тестирование, а DDoS.

Follow-up: Как изменится профиль нагрузки при переходе с REST на gRPC?

5. OWASP Top 10 — что должен знать QA?

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

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

OWASP Top 10 — список самых критичных уязвимостей веб-приложений. QA должен знать минимум 5 и уметь проверять:

• SQL Injection — ввести ' OR 1=1 -- в поля ввода, проверить параметризацию запросов
• XSS (Cross-Site Scripting) — ввести <script>alert('xss')</script> в текстовые поля, проверить экранирование
• Broken Authentication — проверить: сессии истекают, токены не предсказуемы, есть rate limiting на логин
• IDOR (Insecure Direct Object Reference) — подменить ID в URL/API и проверить, виден ли чужой ресурс. GET /api/orders/123 → GET /api/orders/124
• Security Misconfiguration — дефолтные креды, открытые debug-эндпоинты, CORS *

QA не заменяет пентестера, но должен ловить очевидные уязвимости. Интеграция DAST (OWASP ZAP) и SAST (SonarQube, Semgrep) в CI/CD — ответственность Senior QA.

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

Follow-up: Как встроить security-тестирование в CI/CD без замедления пайплайна?

6. Как тестировать приложения с LLM/AI?

Интервьюер проверяет: готов ли ты к реалиям 2026 года, где AI — часть почти каждого продукта.

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

Тестирование AI-приложений отличается от классического — нет детерминированного «правильного ответа». Подходы:

• Golden Dataset — набор эталонных пар «вопрос → ожидаемый ответ». Проверяем, что модель не деградировала
• LLM-as-Judge — используем другую LLM для оценки ответов по критериям: релевантность, полнота, отсутствие галлюцинаций
• Regression Testing — при обновлении модели/промпта сравниваем выходы на том же датасете
• Red Teaming — целенаправленные попытки сломать модель: prompt injection, получение запрещённого контента
• Latency и Cost — AI-запросы дорогие и медленные. Мониторим среднее время ответа и стоимость за запрос

Главная сложность: недетерминированность. Один и тот же промпт может давать разные ответы. Тесты должны проверять смысл, а не точное совпадение строк.

Типичная ошибка: Пытаться тестировать LLM-ответы через assertEqual. Или вообще не знать, что эта тема существует — в 2026 году это уже не экзотика.

Follow-up: Как измерить качество RAG-системы (Retrieval-Augmented Generation)?

Технические вопросы позади. Финальный блок — про управление процессом и коммуникацию.

7. Root Cause Analysis — как проводить?

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

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

RCA (Root Cause Analysis) — метод поиска коренной причины дефекта, а не поверхностного симптома. Основные техники:

• 5 Why — задаёшь вопрос «Почему?» последовательно 5 раз, пока не дойдёшь до корня
• Fishbone (Ishikawa) — диаграмма причин по категориям: люди, процессы, инструменты, окружение

Пример «5 Why»:

1. Почему на проде упала оплата? → Сервер вернул 500
2. Почему 500? → Таймаут при обращении к платёжному шлюзу
3. Почему таймаут? → Шлюз не отвечал более 30 секунд
4. Почему не отвечал? → Был задеплоен с неверным конфигом
5. Почему с неверным конфигом? → Конфиги не проверяются в CI/CD

RCA-выход: добавить валидацию конфигов в пайплайн.

Типичная ошибка: Остановиться на первом «Почему» и зафиксировать «сервер упал» как причину. Это симптом, а не причина.

Follow-up: Когда RCA не нужен? Все ли баги требуют глубокого анализа?

8. Продайте тестирование клиенту, который не хочет за него платить

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

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

Аргументы на языке денег и рисков:

1. Стоимость бага на проде vs на этапе разработки — исправление бага на продакшене стоит в 30–100 раз дороже (по данным IBM и NIST). Один инцидент с потерей данных пользователей может стоить репутации и штрафов.

2. ROI тестирования — конкретный пример: «На прошлом проекте инвестиция в автоматизацию регрессии за 3 месяца сократила время релиза с 2 недель до 2 дней и предотвратила 3 критических инцидента на проде».

3. Метрика Change Failure Rate — «Без тестирования каждый третий деплой ломает что-то на проде. С тестированием — каждый двадцатый. Это прямая экономия на инцидентах и поддержке».

4. Конкурентное преимущество — стабильный продукт = лояльные пользователи = меньше оттока = больше дохода.

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

Follow-up: Клиент согласился на тестирование, но даёт бюджет только на одного QA. Как расставишь приоритеты?

Итого Senior: 8 вопросов. Фокус — стратегия, метрики, безопасность, AI и бизнес-коммуникация. Senior QA — это не тот, кто знает больше инструментов, а тот, кто умеет выстраивать процесс качества и доносить его ценность до бизнеса.

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

• Стратегия: Прочти «Lessons Learned in Software Testing» (Kaner, Bach, Pettichord) — классика, которая не устарела
• Метрики: Изучи DORA metrics (Accelerate book) — это то, о чём спрашивают на Senior-уровне
• Нагрузка: Пройди курс по k6 (k6.io/docs) и проведи нагрузочное тестирование pet-проекта
• Безопасность: OWASP Testing Guide — бесплатный, исчерпывающий. Попрактикуйся на OWASP Juice Shop
• AI: Изучи фреймворки для evaluation LLM: RAGAS, DeepEval, LangSmith
• Время на подготовку: 3–6 недель, фокус на практике и формулировке опыта

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

• Детали синтаксиса Selenium — это Middle-уровень, Senior должен знать паттерны и архитектуру
• Ручное выполнение тест-кейсов — Senior проектирует процесс, а не выполняет кейсы
• Теорию тестирования по учебнику — от Senior ждут опыт и мнение, а не определения

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

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

1. Зайди на sobesai.app и скачай приложение
2. Запусти перед собеседованием или тренировкой
3. AI слушает вопросы и подсказывает структурированные ответы
4. Потренируй стратегические вопросы — именно на них Senior-кандидаты чаще всего «плавают»

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