Оценка и блокеры

Updated Jul 2026

Оценка тестового усилия

Когда команда оценивает стори-поинты, тестовое усилие должно быть включено. История -- это не «2 поинта на разработку, а потом QA протестирует». Это 2 поинта суммарно, включая тестирование. Если команда систематически недооценивает тестовое усилие, истории переносятся в следующий спринт, и QA становится узким местом.

Факторы, увеличивающие тестовое усилие

Руководство по оценке

Когда команда оценивает историю, QA должен учитывать:

1. Сколько тест-кейсов необходимо? Простое исправление бага может потребовать 2-3 теста. Новая фича может потребовать 20+.
2. Готова ли тестовая инфраструктура? Если нужна настройка page objects, тестовых данных или окружений, добавьте время.
3. Сколько окружений/браузеров? Умножьте усилие на количество платформ.
4. Есть ли зависимости? Внешние API, общие тестовые данные или другие истории, которые должны быть завершены первыми.
5. Каков уровень риска? Высокорисковые фичи (оплата, аутентификация) требуют более тщательного тестирования.

Антипаттерн оценки QA

Команда: "Эта история на 3 поинта."
QA: "Но тестирование займёт 2 дня."
Команда: "Мы добавим отдельную задачу на тестирование."

Это неправильно. Если тестирование отделено от истории, статус «сделано» истории теряет смысл. Тестовое усилие должно быть заложено в оценку истории.

Лучший подход:

Команда: "Эта история на 3 поинта."
QA: "Учитывая необходимое тестирование (3 браузера, интеграция с платёжным API,
      6 граничных случаев), я думаю, это на 5."
Команда: "Давайте обсудим. Можем ли мы разделить, чтобы снизить риск?"

Поднятие блокеров

Блокер -- это всё, что мешает вам завершить тестовую работу. Поднимайте блокеры рано, чётко и публично. «Я не могу протестировать поток оформления заказа, потому что песочница оплаты недоступна» -- это блокер для стендапа, а не что-то, о чём можно упомянуть мимоходом в конце спринта.

Формат блокера

Каждый блокер должен содержать три элемента информации:

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

Примеры блокеров

БЛОКЕР: Невозможно протестировать SHOP-789 (поток оформления заказа)
ПРИЧИНА: Песочница оплаты возвращает 503 с понедельника
ТРЕБУЕТСЯ: Провайдеру восстановить сервис (тикет #45678 заведён)
ОБХОДНОЙ ПУТЬ: Можно тестировать пути оформления без оплаты; тесты оплаты отложены

БЛОКЕР: Невозможно запустить интеграционные тесты
ПРИЧИНА: Staging-база данных не обновлена текущей схемой
ТРЕБУЕТСЯ: DevOps запустить скрипт миграции на staging-db
ОБХОДНОЙ ПУТЬ: Запуск тестов против локальной базы данных (частичное покрытие)

БЛОКЕР: Невозможно протестировать SHOP-801 (email-уведомления)
ПРИЧИНА: SHOP-800 (рефакторинг email-сервиса) ещё не задеплоен на staging
ТРЕБУЕТСЯ: Разработчику задеплоить SHOP-800 на staging
ОБХОДНОЙ ПУТЬ: Нет -- тесты email зависят от нового сервиса

Эскалация блокеров

Agile QA-чек-лист

Используйте этот чек-лист, чтобы ничего не выпало из внимания во время спринта.

Перед спринтом

• Изучить предстоящие истории на тестируемость и ясность
• Определить тестовые зависимости (окружения, данные, инструменты)
• Подготовить тестовые окружения и тестовые данные
• Написать черновые тест-кейсы из критериев приёмки
• Проверить стабильность и надёжность CI-пайплайна
• Убедиться, что исправления нестабильных тестов предыдущего спринта задеплоены

Во время спринта

• Участвовать во всех церемониях и вносить QA-перспективу
• Тестировать инкрементально по мере завершения фич (не накапливать к концу)
• Сообщать о блокерах немедленно на стендапе
• Заводить дефекты с чёткими шагами воспроизведения и доказательствами
• Обновлять инструменты управления тестированием результатами выполнения
• Работать в паре с разработчиками над сложными тестовыми сценариями
• Проводить сессии исследовательского тестирования на завершённых фичах

Конец спринта

• Проверить, что все истории соответствуют Definition of Done
• Запустить полный регрессионный набор (автоматизированный)
• Завести и сообщить об оставшихся дефектах
• Подготовить метрики качества для обзора спринта
• Участвовать в ретроспективе с данными о качестве
• Задокументировать, что было протестировано и что нет (заметки к релизу)

Между спринтами

• Устранить нестабильные тесты и проблемы тестовой инфраструктуры
• Рефакторить тестовый код, ставший трудным для поддержки
• Обновить тестовую документацию и материалы онбординга
• Исследовать новые инструменты или подходы для предстоящих фич
• Пересмотреть и обновить Definition of Done при необходимости
• Подготовиться к потребностям тестирования следующего спринта

Скорость спринта и QA

Если скорость команды непостоянна, тестовое усилие часто является скрытой переменной. Отслеживайте эти метрики для понимания влияния:

Если истории постоянно накапливаются в «тестировании» к концу спринта, у команды три варианта:

1. Уменьшить скоуп спринта: брать меньше историй, чтобы у тестирования было достаточно времени
2. Сдвинуть влево: начинать тестирование раньше (см. shift-left-тестирование)
3. Больше автоматизировать: сократить время ручного тестирования автоматизацией регрессии

Практическое упражнение

1. Изучите истории текущего спринта. Для каждой оцените, было ли тестовое усилие адекватно учтено.
2. Определите ваши текущие блокеры и опишите их в трёхчастном формате выше.
3. Используйте agile QA-чек-лист для следующего спринта. Отслеживайте, какие пункты вы систематически пропускаете.
4. Предложите изменение в процессе оценки вашей команды, которое лучше учитывает тестовое усилие.
5. Измерьте, сколько историй заканчивают спринт «в тестировании» vs «сделано». Есть ли паттерн?