Собеседования по системному дизайну для QA

Собеседования по системному дизайну для QA отличаются от таких же для разработчиков. Вместо проектирования самой системы вас просят спроектировать стратегию и инфраструктуру тестирования.

Фреймворк QA System Design

1. Уточнить требования

  • Масштаб (пользователи, RPS, объём данных)
  • SLA (uptime, латентность, error rate)
  • Существующие окружения
  • Частота деплоев
  • Текущее тестирование

2. Определить слои тестирования

Unit Tests → Integration Tests → Contract Tests → E2E Tests → Performance Tests → Chaos Engineering

3. Спроектировать тестовую архитектуру

Для каждого слоя: инструменты, CI-триггеры, где выполняются, репортинг, действия при сбое.

Типичные сценарии

Сценарий 1: E-commerce платформа на микросервисах

Система: 15 микросервисов (auth, каталог, корзина, платежи, доставка, уведомления)

Подход:

  • Unit-тесты: Каждый сервис, запуск на каждый коммит
  • Контрактные тесты: Pact для consumer-driven контрактов
  • Интеграционные: TestContainers для пар сервисов
  • E2E: Критические пользовательские пути (каталог → корзина → оформление → оплата)
  • Нагрузочные: k6 на 1000 RPS для checkout-потока
  • Chaos engineering: Тестирование устойчивости при отказах сервисов

Сценарий 2: Система обмена сообщениями в реальном времени

Подход:

  • Property-based testing для порядка сообщений
  • Тесты конкурентности с множественными producer/consumer
  • Симуляция сетевых разрывов
  • Длительные тесты стабильности (soak testing)

Сценарий 3: ML-пайплайн

Подход:

  • Валидация данных (Great Expectations)
  • Бенчмарки модели на эталонных датасетах
  • Инфраструктура A/B-тестирования
  • Shadow-тестирование перед продакшеном

Презентация решения

  1. Переформулировать задачу (30 сек)
  2. Уточняющие вопросы (2-3 мин)
  3. Высокоуровневый подход (2-3 мин)
  4. Детальный дизайн с диаграммами (10-15 мин)
  5. Компромиссы и альтернативы (3-5 мин)

Упражнение: Спроектируйте тестовую архитектуру

Спроектируйте стратегию тестирования для приложения доставки еды: мобильные приложения, дашборд ресторана, приложение курьера, 10 микросервисов, отслеживание в реальном времени, обработка платежей, 50K заказов в день.

Структура решения

Слой 1 — Unit-тесты: Каждый микросервис, модули мобильных приложений Слой 2 — Контрактные тесты: Pact между приложениями и бэкендом Слой 3 — Интеграционные: Платёжный шлюз, сервис карт, уведомления Слой 4 — E2E:

  • Клиент: каталог → заказ → оплата → отслеживание → получение
  • Ресторан: получить заказ → приготовить → отметить готовым
  • Курьер: принять → навигация → забрать → доставить Слой 5 — Нагрузочные: Пиковая нагрузка (обед/ужин) Слой 6 — Мобильные: Offline-режим, точность GPS, батарея Слой 7 — Chaos: Отказы сервисов, деградация сети

Ключевые выводы

  • QA system design — о стратегии тестирования, не об архитектуре системы
  • Начинайте с понимания масштаба, SLA и текущего тестирования
  • Проектируйте тестирование послойно: unit, интеграционные, контрактные, E2E, нагрузочные, chaos
  • Обсуждайте компромиссы явно — идеального решения не существует