🎯 Блок 01 — Теория тестирования QA

Тест-дизайн · Метрики · Пирамида · Shift-left · Flaky · Покрытие · Трассировка

🎨 1. Техники тест-дизайна

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

Делим все возможные входные данные на классы эквивалентности. Тестируем по одному значению из каждого класса — если одно работает, остальные из того же класса тоже должны.

Поле	Классы	Значения для тестов
Возраст (18–65)	до 18, 18–65, 65+	17, 30, 66
Рейтинг (1–5)	меньше 1, 1–5, больше 5	0, 3, 6
Email	пустой, невалидный, валидный	"", "abc", "a@b.c"

Граничные значения (Boundary Value Analysis)

Баги чаще всего на границах классов. Проверяем само граничное значение ± 1.

Граница	Проверяем
18 лет (минимум)	17, 18, 19
65 лет (максимум)	64, 65, 66
Пароль 8 символов	7, 8, 9

Комбо: Эквивалентное разделение + граничные значения — чаще всего используются вместе и дают основу тест-кейсов.

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

Когда результат зависит от комбинации условий. Каждая колонка = один тест-кейс.

Условие	1	2	3	4
Есть аккаунт?	Да	Да	Нет	Нет
Правильный пароль?	Да	Нет	—	—
Результат	✅ Вход	❌ Ошибка	📝 Регистрация	📝 Регистрация

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

Вместо тестирования всех комбинаций всех параметров — тестируем все попарные комбинации. Это покрывает большинство дефектов.

Пример: 3 браузера × 3 ОС × 3 языка = 27 комбинаций. Pairwise → ~9 тестов.

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

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

На практике: Exploratory — дополнение к формальным техникам, не замена. Используется когда мало времени или неясны требования.

📊 2. Метрики тестирования

Метрика	Формула / Суть	Что показывает
Defect Density	Кол-во багов / размер (KLOC, модули)	Где больше всего багов — где тестировать тщательнее
Test Pass Rate	(Pass / Total) × 100%	% прошедших тестов. Низкий = проблемы с качеством
Defect Leakage	Баги на проде / все баги × 100%	Сколько багов пропустили. Чем ниже — тем лучше QA
MTTR	Среднее время исправления бага	Как быстро команда реагирует на проблемы
Test Coverage	% покрытия требований/кода тестами	Насколько полно протестировали
Defect Removal Efficiency	Баги до релиза / (баги до + баги после) × 100%	Эффективность процесса тестирования

Defect Leakage = (баги найденные на PROD / все баги) × 100%

DRE = (баги до релиза / (баги до релиза + баги после)) × 100%

🔺 3. Пирамида тестирования

Unit Tests (много, быстро, дёшево)
Integration Tests (умеренно)
E2E / UI Tests (мало, медленно, дорого)

Уровень	Что тестирует	Скорость	Стоимость	Кол-во
Unit	Отдельные функции/методы	⚡ мс	💰 низкая	Много
Integration	Взаимодействие модулей, API, БД	⏱ секунды	💰💰 средняя	Умеренно
E2E / UI	Полные сценарии через UI	🐢 минуты	💰💰💰 высокая	Мало

Правило: Много unit-тестов внизу, умеренно интеграционных, мало E2E наверху. Если пирамида перевёрнута (много E2E, мало unit) — это антипаттерн «рожок мороженого».

⬅️ 4. Shift-Left Testing

Shift-left — подход, при котором тестирование сдвигается влево по timeline проекта (т.е. начинается как можно раньше).

Традиционно: требования → разработка → тестирование → релиз

Shift-left: тестирование参与 с этапа требований → разработка с тестами → быстрый релиз

Что меняется

QA участвует в обсуждении требований (находим неясности ДО кода)
Пишем тест-кейсы параллельно с разработкой
Используем статический анализ, ревью кода
TDD/BDD — тесты пишутся ДО кода

Зачем

Баг, найденный на этапе требований = x1 стоимость
Баг на этапе тестирования = x10 стоимости
Баг на проде = x100 стоимости

⚠️ На собеседовании: «Shift-left — это не значит, что QA работает раньше. Это значит, что качество — ответственность всей команды, а не только QA».

🎲 5. Flaky-тесты

Flaky-тест — тест, который то проходит, то падает без изменений в коде. Результат непредсказуем.

Причины

Рассинхрон (timing): тест не дожидается загрузки элемента
Зависимость от данных: тестовые данные меняются или недоступны
Порядок выполнения: тесты влияют друг на друга (shared state)
Внешние зависимости: API, сеть, БД нестабильны
Неправильные ожидания: hardcoded waits вместо явных условий

Как бороться

Помечать flaky-тесты и анализировать причину
Использовать явные ожидания (wait for condition) вместо sleep
Изолировать тесты: каждый тест — независимый
Использовать test data factories вместо общих данных
Мониторить flakiness rate (% падений)

На собеседовании: «Flaky-тесты подрывают доверие к тестам. Если команда видит, что тест иногда красный — начинается игнорирование. Поэтому flaky-тесты нужно либо фиксить, либо временно отключать из пайплайна.»

📐 6. Покрытие тестами (Test Coverage)

Виды покрытия

Вид	Что измеряет	Пример
Покрытие кода	% строк / веток / функций, выполненных тестами	80% строк кода вызваны тестами
Покрытие требований	% требований с тест-кейсами	40 из 50 требований → 80%
Покрытие функций	% функциональных модулей, покрытых тестами	10 из 12 экранов протестированы

Метрики покрытия кода

Метрика	Суть
Line Coverage	% строк кода, которые выполнились
Branch Coverage	% веток if/else, которые выполнились
Function Coverage	% функций, которые были вызваны
Statement Coverage	% операторов, которые выполнились

⚠️ 100% покрытие кода ≠ отсутствие багов. Покрытие показывает ЧТО выполнилось, но не ЧТО проверилось.

🔗 7. Трассировка (Traceability Matrix)

Матрица трассировки — таблица, связывающая требования ↔ тест-кейсы ↔ баги.

Пример

Требование	Тест-кейс	Статус	Баг
R-01: Логин по email	TC-01, TC-02	✅ Pass	—
R-02: Восстановление пароля	TC-03	❌ Fail	BUG-15
R-03: OAuth Google	—	⚠️ Нет теста	—

Зачем нужна

Цель	Пояснение
Покрытие	Видно, к каким требованиям нет тестов
Анализ влияния	Если меняется требование — сразу видно какие тесты затронуты
Отчётность	Для заказчиков / аудита — доказательство тестирования
Связь баг ↔ требование	Понятно, какая функциональность сломана

Виды трассировки:

Forward: требование → тест-кейс (проверяем покрытие)
Backward: баг → требование (понимаем что сломано)
Bi-directional: оба направления, полная матрица

💬 Вопросы для самопроверки

❓ В чём разница между эквивалентным разделением и граничными значениями? Эквивалентное разделение — делим на классы и берём по одному из каждого. Граничные значения — фокус на границах классов (±1). Обычно используются вместе: сначала классы, потом проверяем границы каждого.

❓ Что такое «рожок мороженого» в контексте тестирования? Антипаттерн — когда E2E/UI тестов больше, чем unit-тестов. Это плохо: E2E медленные, хрупкие, дорогие в поддержке. Пирамида должна быть шире внизу (unit) и уже сверху (E2E).

❓ Что такое shift-left и зачем он нужен? Подход, при котором тестирование начинается как можно раньше — с этапа требований. Баг на этапе требований стоит в 10–100 раз дешевле, чем на проде. Shift-left — не про «QA работает раньше», а про «качество — ответственность всей команды».

❓ Что такое flaky-тест и почему он опасен? Тест, который непредсказуемо проходит/падает без изменений кода. Опасен тем, что команда начинает игнорировать красные тесты — «oh, это просто flaky». Подрывает доверие к автоматизации. Нужно: фиксить, изолировать, использовать явные ожидания.

❓ 100% code coverage гарантирует отсутствие багов? Нет. Coverage показывает что код ВЫПОЛНИЛСЯ, но не что он ПРОВЕРИЛСЯ правильно. Можно вызвать все строки, но не проверить edge cases. Coverage — полезная метрика, но не цель.

❓ Для чего нужна матрица трассировки? Связывает требования ↔ тест-кейсы ↔ баги. Показывает: 1) какие требования не покрыты тестами, 2) какие тесты затронуты при изменении требования, 3) какие требования сломаны багом.

❓ Что такое Defect Leakage и как считается? Доля багов, которые «протекли» на прод. Формула: (баги на проде / все баги) × 100%. Чем ниже — тем лучше QA-процесс.