Процесс и управление тестированием
Тестирование живёт не в вакууме, а внутри процесса разработки. Здесь важно не «нажать кнопку», а ответить: по какой модели идёт проект, какой у команды подход к качеству, что и в каком объёме мы покрываем, как доказать, что покрытие достаточно, и какими релизными активностями проверяем продукт перед выпуском в мир. Это уровень тест-менеджмента — и именно его спрашивают на middle- и senior-собеседованиях.
Ловушки тут концептуальные, а не синтаксические: кандидаты переворачивают alpha и beta, путают стратегию с планом, приравнивают 100% покрытия строк кода к полному покрытию, а A/B-тест принимают за поиск дефектов. Ниже — карта из восьми слоёв: от моделей SDLC и планирующих документов к покрытию, трассировке и релизным видам тестирования. Каждый слой заземлён на таблицу, диаграмму или разобранный пример.
Карта темы
- Модели SDLC — Waterfall, Scrum и Kanban и то, где в каждой находится тестирование.
- Стратегия против тест-плана — высокоуровневый подход организации против документа под конкретный релиз.
- Тест-анализ против тест-дизайна — ЧТО тестировать (условия) против КАК (конкретные кейсы).
- Покрытие тестами — привязка покрытия к требованиям и риску, а не к строкам кода.
- Матрица трассировки — сопоставление требований с тест-кейсами, где пустая строка это видимая дыра.
- Исследовательское тестирование — тест без спецификации через построение ментальной модели продукта.
- Alpha- и beta-тестирование — внутренняя приёмка против полевого теста реальными пользователями.
- A/B-тестирование — эксперимент на живом трафике для оптимизации метрики, а не поиск дефектов.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Путать, какая модель последовательная (Waterfall), а какая итеративная (Scrum) | Неверная картина того, где в цикле находится тестирование |
| Считать стратегию и тест-план взаимозаменяемыми | Теряется разница между стабильным подходом и планом под релиз |
| Менять местами тест-анализ (ЧТО) и тест-дизайн (КАК) | Прыжок к написанию кейсов без выведения тестовых условий |
| Приравнивать 100% покрытия строк кода к полному покрытию | Непокрытые требования остаются невидимыми |
| Считать тест-кейсы вместо привязки их к требованиям | Матрица трассировки не выявляет дыры |
| Заводить незадокументированное поведение как баг без подтверждения | Ложные дефекты вместо вопроса аналитику или PO |
| Переворачивать, что alpha внутри и раньше, а beta снаружи и позже | Путаница, кто и когда тестирует релиз |
| Считать A/B-тестирование техникой поиска дефектов | Смешение эксперимента на метрике с проверкой требований |
Значение для собеседований
Процессные вопросы проверяют, мыслите ли вы на уровне тест-менеджмента, а не только исполнителя тест-кейсов. Кандидат, который различает стратегию и план, привязывает покрытие к требованиям через матрицу трассировки и умеет выстроить процесс в команде без него, сразу выглядит на грейд выше.
Что обычно проверяют:
- Модели разработки и где в каждой находится тестирование (Waterfall, Scrum, Kanban).
- Разницу между стратегией и тест-планом, тест-анализом и тест-дизайном.
- Как доказать достаточность покрытия — требования, риск, матрица трассировки, а не строки кода.
- Релизные виды тестирования — alpha, beta, A/B — и чем эксперимент отличается от поиска дефектов.
Типичный неверный ответ: «покрытие достаточно, когда 100% строк кода выполнены». На самом деле покрытие строк кода не гарантирует, что каждое требование проверено — полное покрытие привязано к требованиям и остаточному риску, а трассировка показывает, какие требования остались без кейса.