Плейбук тестировщика

1. Введение в плейбук тестировщика

Этот плейбук — полный справочник по теории и практике тестирования программного обеспечения. Он охватывает все виды и типы тестирования, техники тест-дизайна и методы расчёта количества тест-кейсов. Материал структурирован для быстрого поиска и практического применения.

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

2. Классификация видов и типов тестирования

Тестирование ПО классифицируется по множеству признаков. Ниже приведены основные классификации с подробными таблицами.

2.1 По уровню тестирования (Test Levels)

Подвиды по уровню:

• Component testing: тестирование больших компонентов (модулей), состоящих из множества классов
• Integration testing: может быть Big Bang (все сразу) или Incremental (постепенно: Top-Down, Bottom-Up)
• System Integration: взаимодействие с внешними системами (Third-party API, DB, legacy)
• Alpha / Beta testing: подвид приемочного — на стороне разработчика / у ограниченного круга пользователей

2.2 По знанию внутреннего устройства (Test Approaches)

White Box техники:

• Statement Coverage: каждая строка кода выполнена хотя бы раз
• Branch Coverage: каждое условие (if/else) было true и false
• Path Coverage: каждый возможный путь в коде пройден
• Condition Coverage: каждый атомарный булевый подвыражение — true и false
• MC/DC (Modified Condition/Decision Coverage): каждое условие независимо влияет на решение — стандарт для DO-178C (авиация)

2.3 По степени автоматизации

Что стоит автоматизировать:

• Регрессионные тесты (Core functionality)
• Smoke-тесты при каждом деплое
• API-тесты (быстрые, стабильные)
• Тесты производительности (нагрузка)
• Data-driven тесты (много данных)

2.4 По целям и задачам

2.5 Функциональное тестирование (Functional Testing)

Проверка, что система выполняет заявленные функции в соответствии с требованиями.

2.6 Нефункциональное тестирование (Non-Functional Testing)

Подвиды Performance тестирования:

• Spike testing: резкий скачок нагрузки (например, Black Friday)
• Volume testing: обработка большого объёма данных
• Capacity testing: определение максимальной ёмкости системы
• Latency testing: задержка при передаче данных
• Throughput testing: пропускная способность (транзакций/сек)

2.7 По времени выполнения тестов

Методы статического тестирования:

• Informal review: неформальное обсуждение кода/документации
• Walkthrough: автор ведёт участников по материалу
• Technical review: техническая экспертиза коллегами
• Inspection: формальная проверка с ролями (автор, чтец, секретарь)
• Static analysis: автоматическая проверка кода без запуска

3. Техники тест-дизайна (Test Design Techniques)

Техники тест-дизайна — это методы создания тестов, обеспечивающие максимальное покрытие при минимальном количестве тест-кейсов. Каждая техника имеет свою формулу расчёта количества тестов.

3.1 Эквивалентное разделение (Equivalence Partitioning / EP)

Суть: Разбиение входных данных на классы эквивалентности, внутри которых система ведёт себя одинаково. Из каждого класса выбирается один представитель.

Правила выделения классов:

• Корректные (валидные) классы: данные, которые система должна успешно обработать
• Некорректные (невалидные) классы: данные, которые система должна отклонить
• Каждый класс содержит бесконечное количество значений, эквивалентных в поведении
• Если один представитель класса проходит — весь класс считается пройденным
• Один дефект может покрывать целый класс (bug masking)

Пример:

Поле «Возраст» принимает значения от 18 до 60:

Количество тестов: 3 (по одному на каждый класс)

3.2 Анализ граничных значений (Boundary Value Analysis / BVA)

Суть: На границах классов эквивалентности система наиболее склонна к ошибкам. Проверяются значения на границе, чуть выше и чуть ниже.

Варианты:

• 2-value BVA: граничное значение и следующее за границей (min, min+1), (max-1, max)
• 3-value BVA: граничное значение, предыдущее и следующее (min-1, min, min+1)
• Robust BVA: учитывает выход за пределы допустимого диапазона
• Worst-case BVA: все комбинации границ всех параметров

Пример для поля «Возраст» (18-60) — 2-value BVA:

Количество тестов: 2-value = 5 тестов; 3-value = 7 тестов (17,18,19,59,60,61 + 1 граничный)

3.3 Таблица принятия решений (Decision Table Testing)

Суть: Систематизация комбинаций условий (Causes) и соответствующих действий (Effects). Каждая комбинация — отдельный тест.

Структура таблицы:

• Conditions (Условия): бинарные входные данные (True/False)
• Actions (Действия): ожидаемый результат
• Rules (Правила): каждая колонка — одна комбинация
• Culling: удаление невозможных комбинаций

Пример: логин в систему

Количество тестов: 2² = 4 (полный перебор) → после culling: 3 (правила 3 и 4 могут быть объединены)

3.4 Тестирование состояний и переходов (State Transition Testing)

Суть: Система рассматривается как конечный автомат. Тесты покрывают переходы между состояниями и проверяют недопустимые переходы.

Элементы:

• States (Состояния): режимы системы (LoggedOut, LoggedIn, Error, Locked)
• Transitions (Переходы): события, меняющие состояние (Login, Logout, Error)
• Events (События): триггеры переходов
• Invalid transitions: события, которые не должны срабатывать в данном состоянии

Пример: банковское приложение

Количество тестов = 4 (состояния) + 4 (валидных перехода) + 2 (недопустимых) = 10 тестов

Разновидности:

• 0-switch (State Coverage): каждое состояние посещено хотя бы раз
• 1-switch (Transition Coverage): каждый переход проверен
• N-switch: последовательности из N переходов — полное покрытие путей

3.5 Попарное тестирование (Pairwise / All-Pairs)

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

Алгоритм:

1. Определить параметры и их значения
2. Построить all-pairs таблицу
3. Проверить, что каждая пара значений встретилась хотя бы один раз
4. Добавить «подозрительные» комбинации (приоритетные)

Пример:

Полный перебор: 3×3×2 = 18 тестов. Pairwise: 6-9 тестов (экономия 50-70%).

3.6 Ортогональные массивы (Orthogonal Arrays / OATS)

Суть: Математический метод комбинаторного тестирования, использующий ортогональные массивы для минимизации количества тестов при сохранении равномерного покрытия.

Примеры массивов:

Для 4 параметров по 3 значения: полный перебор = 3⁴ = 81; ортогональный массив L₉ = 9 тестов.

Отличие от Pairwise:

• Pairwise покрывает все пары — OATS покрывает равномерно
• OATS жёстче математически, но иногда даёт больше тестов
• OATS требует таблицы массивов, Pairwise — алгоритм

3.7 Тестирование на основе сценариев использования (Use Case Testing)

Суть: Тесты создаются на основе реальных сценариев использования системы, описанных в Use Case или User Story.

Структура Use Case теста:

Пример расчёта:

Use Case «Оформление заказа»:

• Основной поток: 1 тест (успешный заказ)
• Альтернативные: 3 (разные способы оплаты)
• Исключительные: 4 (недостаточно средств, товар закончился, ошибка платёжного шлюза, превышение лимита)

Итого: 1 + 3 + 4 = 8 тест-кейсов

3.8 Error Guessing (Угадывание ошибок)

Суть: Основана на интуиции и опыте тестировщика. Тесты создаются на основе типовых ошибок, ранее найденных дефектов и известных «болевых точек».

Типовые сценарии Error Guessing:

• Пустые значения: submit пустой формы
• Нулевые значения: деление на 0, скидка 0%
• Отрицательные значения: количество товара -1
• Граничные значения имён: 1 символ, 256 символов, пробелы, спецсимволы
• Одновременный доступ: два пользователя редактируют одну запись
• Прерывания: обрыв соединения, потеря питания
• Кэш: устаревшие данные в кэше
• Race conditions: одновременный вызов API несколько раз
• SQL-инъекции: «' OR 1=1; --»
• XSS: «<script>alert('XSS')</script>»

3.9 Исследовательское тестирование (Exploratory Testing)

Суть: Одновременное изучение, проектирование и выполнение тестов. Тестировщик самостоятельно исследует продукт, принимая решения на основе полученных результатов.

Подходы:

• Freestyle: без ограничений, полная свобода
• Session-based: тайм-бокс (45-90 мин), чартер (цель сессии), отчёт
• Scenario-based: сценарии от реальных пользователей
• Tour-based: «экскурсии» — тестирование по определённому маршруту (Подвал, Квартал красных фонарей, Аллея супермена)

Структура сессии (Session-Based Test Management — SBTM):

3.10 Classification Tree Method (CTM) / Метод классификационных деревьев

Суть: Графическая техника для систематического разбиения входных данных на классификационные классы. Каждый класс разбивается на подклассы, формируя иерархическое дерево.

Пример: тестирование банковского перевода

Банковский перевод
├── Валюта
│   ├── RUB
│   ├── USD
│   └── EUR
├── Сумма
│   ├── Меньше лимита (<100k)
│   ├── На лимите (100k)
│   └── Больше лимита (>100k)
├── Получатель
│   ├── Свой счёт
│   └── Чужой счёт
└── Комиссия
    ├── Включена в сумму
    └── Добавлена сверху

Полный перебор: 3×3×2×2 = 36 комбинаций. После pairwise-сокращения: ~8-12 тестов.

3.11 Доменный анализ (Domain Testing / Domain Analysis)

Суть: Расширение EP + BVA на многомерные домены. Каждый параметр рассматривается как измерение, а набор параметров — как многомерное пространство.

Термины:

• Domain (Домен): множество возможных значений параметра
• ON-point: значение, принадлежащее классу, на границе
• OFF-point: значение, не принадлежащее классу, ближайшее к границе
• IN-point: значение внутри класса (произвольное)
• OUT-point: значение вне класса (произвольное)

Пример для функции расчета доставки:

Параметры: Вес (W: 0-30 кг) и Расстояние (D: 0-500 км). Каждый — по 3 класса.

• ON-points: W=0, W=30, D=0, D=500
• OFF-points: W=-0.01 (или отрицательный), W=30.01, D=-0.01, D=500.01
• IN-points: W=15, D=250
• Всего: (4 ON + 4 OFF + 2 IN) × 2 (для W и D) = 20 тестов

4. Методы расчёта количества тест-кейсов

Правильная оценка количества тест-кейсов критически важна для планирования ресурсов, времени и бюджета тестирования.

4.1 Общие формулы оценки

Метрики на основе размера:

Estimation техники:

4.2 Расчёт количества тестов для Equivalence Partitioning

Пошаговый расчёт:

1. Определить все входные параметры
2. Для каждого параметра выделить валидные и невалидные классы
3. Суммировать общее количество классов

Пример: форма регистрации

N = 4 + 13 = 17 тест-кейсов

4.3 Расчёт для Boundary Value Analysis

Пример для полей с разными диапазонами:

Robust BVA (с выходом за границы):

Для возраста (18-120): -1, 0, 17, 18, 19, 119, 120, 121, 150 = 9 тестов

4.4 Расчёт для Decision Table

Примеры:

4.5 Расчёт для State Transition

По уровням покрытия:

Пример: система с 5 состояниями, 8 переходами, 3 недопустимыми:

N = 5 + 8 + 3 = 16 тестов (transition coverage)

4.6 Расчёт для Pairwise / All-Pairs

Эмпирические правила оценки:

4.7 Практические советы по расчёту общего количества тестов

Итоговая формула для одного модуля/функции:

Коэффициенты сложности:

Коэффициенты на этапы тестирования:

5. Примеры расчёта тест-кейсов

Пример 1: Форма авторизации

Параметры: Логин (строка, 3-50 символов), Пароль (строка, 6-128 символов), Запомнить меня (чекбокс), Captcha (да/нет)

Пример 2: Калькулятор доставки

Параметры: Вес (0-30 кг), Расстояние (0-500 км), Тип доставки (Стандарт/Экспресс/Международная), Страхование (да/нет), Подарочная упаковка (да/нет)

Пример 3: Обработка заказа (REST API)

Параметры: ID заказа (int, >0), Статус (New/Processing/Shipped/Delivered/Cancelled), Тип оплаты (Card/Cash/Transfer), Сумма (decimal, 0.01-1M), Промокод (string, опционально)

6. Тестирование API

API-тестирование — проверка программных интерфейсов (REST, GraphQL, gRPC, SOAP). Это самый эффективный вид тестирования по соотношению скорость/покрытие: API-тесты стабильны, быстры и не зависят от UI.

Уровни API-тестирования

Что проверять в REST API

Техники API-тест-дизайна

• Parameter variation: query/path/header параметры — валидные, невалидные, отсутствующие
• Body mutation: изменение типов полей, пропуск обязательных, лишние поля, null, пустые строки
• Auth testing: без токена, с истёкшим, с невалидным, с правами readonly
• Pagination: page=1&size=0, page=-1, size=10000, cursor-based пагинация
• Filter/Sort: некорректные поля, SQL-инъекции через фильтры
• File upload: пустой файл, очень большой, неверный MIME type, вредоносный
• Rate limiting: превышение лимита, headers X-RateLimit-Remaining, Retry-After

Contract Testing (Consumer-Driven Contracts)

• Provider contract: сервис гарантирует определённый формат ответа
• Consumer contract: клиент ожидает определённый формат
• Инструменты: Pact, Spring Cloud Contract, Postman Collections
• Проверка: breaking changes — изменение поля, удаление эндпоинта, новый required field

7. Баг-репорты (Bug Reports)

Баг-репорт — документ, описывающий дефект в программном обеспечении. Качественный баг-репорт — основа эффективной коммуникации между QA и разработкой.

Структура идеального баг-репорта

Severity vs Priority

Жизненный цикл бага

1. New (Открыт): баг заведён в трекере
2. Assigned (Назначен): назначен разработчику
3. In Progress (В работе): разработчик начал исправление
4. Fixed (Исправлен): код изменён, ждёт тестирования
5. Ready for Test (На тестировании): билд с фиксом готов
6. Verified (Проверен): QA подтвердил исправление
7. Closed (Закрыт): баг закрыт
8. Reopened (Переоткрыт): баг воспроизвёлся снова после фикса
9. Duplicate (Дубликат): такой баг уже существует
10. Won't Fix (Не будет исправлен): решение не исправлять (де-факто фича)

8. Тестовая документация

Тестовая документация — совокупность артефактов, описывающих стратегию, план, процесс и результаты тестирования.

Основные документы

Чек-лист vs Тест-кейс: когда что использовать

Test Report — структура

• Executive Summary: одно предложение о состоянии качества
• Statistics: Passed/Failed/Blocked/Skipped, всего тестов, % прохождения
• Coverage: requirements coverage, code coverage, risk coverage
• Defects: открыто/закрыто, по severity, по компонентам
• Risks: что не протестировано, известные проблемы
• Metrics: DRE, defect density, testing velocity
• Recommendation: релиз разрешён / условно / запрещён

9. Метрики тестирования (KPI)

Метрики позволяют объективно оценить качество продукта и эффективность процесса тестирования.

Основные метрики

Пример отчёта по метрикам

10. Работа с требованиями (Requirements Testing)

Качество тестирования напрямую зависит от качества требований. Плохие требования → плохие тесты → плохой продукт.

Характеристики хорошего требования (SMART)

BDD и Gherkin (Given / When / Then)

Behavior-Driven Development — подход, при котором тесты пишутся на естественном языке по шаблону Gherkin:

Функция: Авторизация пользователя
  Как зарегистрированный пользователь
  Я хочу войти в систему
  Чтобы получить доступ к личному кабинету

  Сценарий: Успешный вход
    Дано я нахожусь на странице входа
    И я ввожу "test@example.com" в поле email
    И я ввожу "password123" в поле пароля
    Когда я нажимаю кнопку "Войти"
    Тогда я вижу сообщение "Добро пожаловать!"
    И я перенаправлен на страницу профиля

  Сценарий: Неверный пароль
    Дано я нахожусь на странице входа
    И я ввожу "test@example.com" в поле email
    И я ввожу "wrong" в поле пароля
    Когда я нажимаю кнопку "Войти"
    Тогда я вижу сообщение "Неверный email или пароль"

Acceptance Criteria (Критерии приёмки)

• Functional: «API возвращает 200 с корректным телом»
• Non-functional: «Время ответа < 300 мс при 50 RPS»
• UI: «Форма центрирована, кнопка синяя (#3B82F6)»
• Error: «При пустом поле показать красную рамку и текст ошибки»

Review требований: чеклист

• Требование однозначно (нет «как правило», «обычно», «удобный»)
• Требование тестируемо (можно написать тест)
• Требование непротиворечиво (не конфликтует с другими)
• Требование полное (не нужно додумывать)
• Требование атомарно (описывает одну вещь)
• Приоритет указан (Must / Should / Could / Won't)

11. Mobile тестирование

Мобильное тестирование имеет множество особенностей по сравнению с веб-тестированием: жесты, прерывания, сетевые условия, ограниченные ресурсы.

Виды мобильного тестирования

Тестирование прерываний (Interruption Testing)

• Входящий звонок: приложение должно свёрнуться, после звонка — восстановиться
• SMS / Push: уведомление не должно сбрасывать состояние
• Будильник: системный алерт не должен ломать UI
• Переключение приложений: состояние сохраняется (app switcher)
• Screen rotation: портрет → лендскейп — данные не теряются
• Low battery: приложение не перегружает CPU при 5% заряда
• Charging: поведение при подключении/отключении зарядки

Эмуляторы vs Реальные устройства

12. Database тестирование

Тестирование базы данных — проверка целостности, производительности и корректности обработки данных.

Что тестировать в БД

SQL-инъекции — тестирование

• «' OR 1=1; --» — обход аутентификации
• «admin' --» — логин без пароля
• «; DROP TABLE users; --» — деструктивные операции
• «' UNION SELECT * FROM passwords; --» — кража данных
• «' OR '1'='1' — то же самое, другой синтаксис

13. Security тестирование (детально)

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

OWASP Top 10 — 2021

Инструменты security-тестирования

Security чеклист для QA

• Все входные данные экранируются (XSS, SQL-инъекции)
• Аутентификация обязательна для защищённых ресурсов
• Сессии истекают, токены рефрешатся
• HTTPS включён, HSTS настроен
• Ошибки не содержат stack trace (production mode)
• Зависимости обновлены, нет известных CVE
• Rate limiting на login/register/API
• File upload — валидация типа, размера, антивирус
• CORS настроен (не '*')
• Security headers: CSP, X-Frame-Options, X-Content-Type-Options

14. Глоссарий терминов тестирования

15. CI/CD и DevOps для QA

CI/CD (Continuous Integration / Continuous Delivery) — практика автоматической сборки, тестирования и доставки кода. QA-инженер должен понимать pipeline, уметь читать логи и настраивать тесты в пайплайне.

Pipeline тестирования

Deploy стратегии

Quality Gates в CI/CD

• Code Coverage: минимальный порог (80%+) — ниже gate не пропускает
• Test Pass Rate: 100% обязательных, >95% всех тестов
• Security Vulnerabilities: 0 critical/high CVE
• Performance Regression: latency не выросла более чем на 5%
• Lint Errors: 0 errors

16. UI / Web тестирование (детально)

UI-тестирование — проверка пользовательского интерфейса и взаимодействия пользователя с приложением.

Инструменты UI-тестирования

Locators: стратегии

Visual Regression Testing

• Pixel-by-pixel: сравнение скриншотов попиксельно (Percy, Applitools, Playwright Screenshot)
• Snapshot testing: сохранение эталонного скриншота и сравнение с новым
• Layout comparison: проверка структуры, а не пикселей (Storybook test)
• Что проверять: все страницы, все viewport (mobile/tablet/desktop), все локали, тёмная/светлая тема
• Threshold: допуск на изменение (0.1% пикселей) — фильтрация шума (antialiasing)

Waits и стабильность UI-тестов

• Auto-wait: Playwright ждёт элемент перед действием (visible, enabled, stable)
• Explicit wait: waitForSelector, waitForNavigation для специфических случаев
• Network idle: waitForLoadState('networkidle') — ждать пока сеть успокоится
• Flaky tests: random timeouts → добавить retries, улучшить локаторы, убрать sleep()

17. Тестирование производительности (детально)

Расширенное руководство по нагрузочному тестированию, выходящее за рамки базовой классификации.

Виды performance-тестов

Bottleneck Analysis

1. CPU: 90%+ user time → алгоритмические проблемы, отсутствие кэширования
2. Memory: рост потребления → утечки (memory leak), неоптимальные структуры
3. Disk I/O: высокий await → медленная БД, неоптимальные запросы, отсутствие индексов
4. Network: высокая latency → CDN, DNS, TLS handshake, большие payloads
5. Database: slow queries → missing indexes, N+1, lock contention
6. External APIs: медленные ответы → добавить timeout, circuit breaker, fallback

Инструменты performance-тестирования

18. Тестирование микросервисов

Микросервисная архитектура требует особого подхода к тестированию из-за распределённой природы, сетевых задержек и независимости сервисов.

Пирамида тестирования микросервисов

Contract Testing (Consumer-Driven Contracts)

• Provider: сервис А гарантирует API
• Consumer: сервис Б использует этот API
• Pact flow: Consumer пишет тест → генерирует Pact файл → Provider верифицирует
• Что проверять: статус-коды, тело ответа, заголовки, новые поля (breaking change)

Service Virtualization (WireMock)

• Создание стабов для внешних сервисов
• Симуляция ответов: success, error, timeout, slow response
• Record/Playback: запись реальных ответов и воспроизведение в тестах
• Stateful stubs: разные ответы в зависимости от состояния

19. Тестирование в Agile/Scrum

QA в Agile — не отдельная фаза, а непрерывный процесс на протяжении всего спринта.

QA в Scrum-церемониях

Definition of Ready (DoR) — чеклист для QA

• User Story имеет acceptance criteria
• Acceptance criteria тестируемы и однозначны
• Дизайн-макеты есть (для UI)
• Тестовые данные определены
• Окружение доступно
• Зависимости от других команд/сервисов учтены

Definition of Done (DoD) — чеклист для QA

• Все acceptance criteria выполнены
• Тест-кейсы написаны и выполнены
• Критические баги отсутствуют
• Автотесты добавлены в регрессию
• Проверено на staging окружении
• Негативные сценарии покрыты

Оценка тестовых усилий (Estimation)

• Planning Poker: команда оценивает сложность в story points
• T-shirt sizes: S (1-2 часа), M (до 4 часов), L (до 8 часов), XL (до 2 дней)
• Test point analysis: количество тест-кейсов × сложность × длительность
• Affinity estimation: группировка и быстрая оценка похожих задач

20. Mutation Testing (Мутационное тестирование)

Мутационное тестирование — метод оценки качества самих тестов. В код вносятся намеренные ошибки (мутации), и проверяется, упадут ли на них тесты.

Типы мутаций (PITest / MutPy)

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

• PITest — Java (стандарт индустрии)
• MutPy — Python
• Stryker — JS/TS, C#, Scala
• Humbug — PHP

Когда применять:

• Критические модули (авторизация, платежи, безопасность)
• После увеличения coverage — проверить, что тесты реально работают
• При code review — мутации подтверждают качество тестов

21. Risk-Based Testing (RBT)

Тестирование, основанное на рисках. Тесты приоритезируются по вероятности и влиянию дефекта. Ресурсы направляются на наиболее рискованные области.

Матрица рисков

Приоритизация тестов по RPN

Пример RBT-анализа для интернет-магазина

22. Root Cause Analysis (RCA)

Анализ корневых причин — метод поиска первопричины проблемы, а не её симптомов. Применяется после критических багов или инцидентов в проде.

Методы RCA

Пример: 5 Whys

Проблема: Пользователи не могут оформить заказ

1. Почему? → API возвращает 500 ошибку
2. Почему? → Запрос к БД падает с timeout
3. Почему? → Таблица заказов заблокирована долгой транзакцией
4. Почему? → Нет индекса на статусе заказа, полное сканирование таблицы
5. Почему? → Отсутствует review миграций перед деплоем (корневая причина ⇐ процесс)

23. Test Environment Management

Управление тестовыми окружениями — одна из самых недооценённых, но критически важных областей QA.

Проблемы тестовых окружений

Типы окружений

• Local / Dev: окружение разработчика, быстрые итерации
• Feature / PR: поднимается на каждый PR (Preview Environments, ephemeral)
• Integration / Staging: общее окружение команды, интеграционные тесты
• Pre-production / Staging: копия продакшена, регрессия, performance-тесты
• Production: smoke-тесты после деплоя, canary

Containerized тестовые окружения (Testcontainers / Docker Compose)

• Testcontainers: поднятие БД/брокеров/кэша в Docker контейнерах для тестов
• Docker Compose: полный стек сервисов для E2E тестов
• Ephemeral environments: автоматическое создание и удаление окружения на каждый PR

24. Тестирование интеграций, ETL и Kafka

Современные системы всё чаще используют event-driven архитектуру с message brokers (Kafka, RabbitMQ) и ETL-пайплайны. Тестирование таких систем требует особого подхода.

Тестирование Kafka

Тестирование ETL-пайплайнов

Dead Letter Queue (DLQ) тестирование

• Невалидные данные: отправка сообщения с неправильным форматом → проверка DLQ
• Ошибки обработки: бизнес-логика выбрасывает exception → сообщение в DLQ после N retries
• Мониторинг DLQ: алерты при появлении сообщений в DLQ
• Re-drive: исправление сообщения и повторная отправка из DLQ

25. Чеклист тестировщика

Планирование и анализ

• Определены виды тестирования для проекта
• Выбраны техники тест-дизайна
• Выделены классы эквивалентности
• Определены граничные значения
• Построены таблицы решений
• Проанализированы состояния и переходы
• Рассчитано примерное количество тест-кейсов
• Оценены временные и ресурсные затраты

Создание тест-кейсов

• Каждый тест-кейс имеет уникальный ID
• Тест-кейс содержит: предусловия, шаги, ожидаемый результат
• Тест-кейсы атомарны (один тест — одна проверка)
• Тест-кейсы независимы (порядок выполнения не важен)
• Покрыты валидные и невалидные классы
• Покрыты положительные и негативные сценарии
• Приоритеты расставлены (Critical / High / Medium / Low)

Coverage (покрытие)

• Requirements coverage > 95%
• Code coverage > 80%
• Branch coverage > 75%
• State coverage (все состояния)
• Transition coverage (все переходы)
• Pairwise покрытие (все пары значений)

Регрессия

• Smoke-тесты выделены и автоматизированы
• Critical path тесты стабильны
• Тесты на граничные значения включены в регрессию
• Проверка старых багов (re-testing)
• Автоматизированные тесты интегрированы в CI/CD
• Время выполнения регрессии < 30 минут

API тестирование

• Все эндпоинты покрыты тестами (200, 4xx, 5xx)
• Contract tests (OpenAPI schema validation)
• Аутентификация/авторизация на каждом эндпоинте
• Rate limiting работает корректно
• Пагинация, фильтры, сортировка
• Idempotency для PUT/DELETE

Баг-репорты

• Заголовок чётко описывает проблему
• Шаги воспроизведения полные и однозначные
• Указана среда (ОС, браузер, версия)
• Приложены скриншоты/видео/логи
• Severity и Priority проставлены
• Нет дубликатов (проверка перед созданием)

Тестовая документация

• Test Plan существует и актуален
• Test Suite структурирован по модулям
• Тест-кейсы атомарны и независимы
• Test Report формируется после каждого цикла
• Метрики собираются и отслеживаются в динамике

Mobile тестирование

• Прерывания (звонок, SMS, уведомления)
• Background/Foreground — сохранение состояния
• Сетевые условия: потеря, переключение, airplane mode
• Разные размеры и плотности экранов
• Батарея и потребление ресурсов
• Установка, обновление, downgrade

Database тестирование

• Constraints (PK, FK, UNIQUE) работают
• CRUD операции корректны
• Транзакции ACID-совместимы
• Миграции протестированы (up/down)
• Нет SQL-инъекций
• Индексы оптимизированы

Security тестирование

• OWASP Top 10 проверен
• SAST/DAST сканирование выполнено
• Зависимости проверены на CVE
• Secrets не хранятся в репозитории
• HTTPS, HSTS, security headers настроены
• Rate limiting на чувствительные эндпоинты

Нефункциональное тестирование

• Performance тесты для критических сценариев
• Load тесты с ожидаемой нагрузкой x2
• Stress тесты до точки отказа
• Security: OWASP Top 10 проверен
• Usability: основные сценарии протестированы
• Accessibility: WCAG 2.1 AA

26. Заключение

Этот плейбук охватывает ключевые аспекты тестирования ПО — от классификации видов и типов до конкретных техник тест-дизайна и методов расчёта количества тест-кейсов. Основные выводы:

• Не существует универсальной техники — комбинируйте EP, BVA, Decision Table, State Transition и Pairwise
• Расчёт количества тестов — не точная наука, а оценка. Используйте формулы как базовую линию, корректируйте под проект
• Покрытие ≠ качество — 100% coverage не гарантирует отсутствие багов. Важна осмысленность тестов
• Автоматизация — серебряная пуля? Нет. Автоматизируйте то, что стабильно, часто выполняется и даёт ценность
• Контекст решает — нет «правильного» набора техник для всех проектов. Адаптируйте подrisks, бюджет и сроки

Плейбук подготовлен для проекта qasdet.github.io • 2026