Почему Оценка Важна
Каждое планирование спринта включает вопрос: «Сколько времени займёт тестирование?» Ошибка имеет реальные последствия:
- Недооценка: Тестирование спешит, баги попадают в продакшен, команда выгорает
- Переоценка: Бюджет тратится впустую, страдает доверие к команде
Факторы, Влияющие на Оценки
| Фактор | Влияние |
|---|---|
| Сложность функционала | Больше сложность = больше тест-кейсов и edge cases |
| Опыт команды | Новая команда или домен = дольше тестирование |
| Качество требований | Размытые требования = больше исследовательского тестирования |
| Зрелость автоматизации | Больше автоматизации = меньше ручного выполнения |
| Стабильность окружения | Нестабильные окружения = блокировки |
| Зависимости | Внешние сервисы = время ожидания |
| Плотность дефектов | Больше багов = больше перепроверок и регрессии |
Техники Оценки
1. Work Breakdown Structure (WBS)
WBS разбивает тестирование на мелкие, оцениваемые задачи.
Пример:
| Активность | Подзадачи | Часы |
|---|---|---|
| Ревью требований | Проверка 20 user stories, критерии приёмки | 12 |
| Проектирование тест-кейсов | Функциональные (40), негативные (20), данные | 28 |
| Выполнение тестов | Ручные (60 кейсов) + автоматизированные | 32 |
| Управление багами | Регистрация, верификация, перепроверка (~15 багов) | 12 |
| Регрессия | Регрессионный набор | 8 |
| Отчётность | Ежедневный статус, финальный отчёт | 4 |
| Итого | 96ч (12 дней) |
2. Three-Point Estimation (PERT)
Три значения: O (Оптимистичная), M (Наиболее вероятная), P (Пессимистичная).
Формула: Оценка = (O + 4M + P) / 6
| Задача | O | M | P | PERT |
|---|---|---|---|---|
| Проектирование кейсов | 12ч | 16ч | 28ч | 17.3ч |
| Выполнение | 16ч | 24ч | 40ч | 25.3ч |
| Управление багами | 4ч | 12ч | 24ч | 12.7ч |
| Регрессия | 4ч | 8ч | 16ч | 8.7ч |
| Итого | 64ч (8 дней) |
3. Wideband Delphi
Техника консенсуса: несколько экспертов оценивают независимо.
Шаги:
- Представить scope 3-5 экспертам
- Каждый оценивает независимо (без обсуждения)
- Собрать оценки анонимно
- Показать все одновременно
- Обсудить крайние значения
- Переоценить (снова независимо)
- Повторить до сходимости (обычно 2-3 раунда)
4. Метод Точек Вариантов Использования
Оценка по количеству и сложности use case.
| Сложность | Количество | Вес | Точки |
|---|---|---|---|
| Простой | 5 | 5 | 25 |
| Средний | 8 | 10 | 80 |
| Сложный | 3 | 15 | 45 |
| Итого | 150 |
Скорректировано: 150 × фактор сложности × производительность = часы тестирования
5. Исторические Данные (На Основе Аналогии)
Использование данных предыдущих похожих проектов.
Точность Оценки во Времени
±50%] --> E2[После требований
±25%] E2 --> E3[После дизайна
±15%] E3 --> E4[Во время тестирования
±5%] end style E1 fill:#F44336,color:#fff style E2 fill:#FF9800,color:#fff style E3 fill:#FFC107,color:#000 style E4 fill:#4CAF50,color:#fff
Ранние оценки по природе менее точны. Учитывайте это, предоставляя диапазоны, а не одиночные числа.
Упражнение: Оценить Трудозатраты Двумя Техниками
Вы — QA-лид проекта системы бронирования отелей. Функционал:
- Регистрация и вход (включая соцсети)
- Поиск отелей (локация, даты, цена, рейтинг)
- Бронирование с оплатой (карта, PayPal)
- Управление бронированиями (просмотр, изменение, отмена)
- Система отзывов
- Панель администратора
Команда: 2 QA (1 senior, 1 middle), опыт в e-commerce, но не в бронировании отелей.
Ваша задача:
- Оценить с помощью WBS
- Оценить с помощью Three-Point
- Сравнить и объяснить, какую представить стейкхолдерам
- Назвать 3 риска
Подсказка
Тестирование оплаты требует дополнительного времени на безопасность. Социальный вход имеет внешние зависимости. Поиск требует тестирования производительности. Не забудьте регрессию и настройку окружения.
Пример решения
WBS: 198ч (~25 дней)
| Активность | Часы |
|---|---|
| Ревью требований + критерии | 20 |
| Проектирование кейсов (105 кейсов) | 56 |
| Подготовка данных | 8 |
| Выполнение (функциональное + безопасность + производительность + кросс-браузерное) | 76 |
| Управление багами (~25 багов) | 16 |
| Регрессия (2 цикла) | 16 |
| Отчётность | 6 |
Three-Point: 189ч (~24 дня)
Диапазон с 95% вероятностью: 127-251ч (16-31 день)
Презентация: «24-25 рабочих дней, с диапазоном 20-31 день в зависимости от плотности дефектов и стабильности окружения.»
Риски:
- Проблемы интеграции с платёжным шлюзом
- Более высокая плотность дефектов, чем ожидалось
- Изменения API социального входа
Типичные Ошибки Оценки
- Забыть задачи, не связанные с тестированием: Настройка окружения, встречи, документация
- Оценивать только happy path: Негативное тестирование занимает столько же
- Игнорировать регрессию: Каждое исправление требует регрессии
- Оценки одним числом: Всегда давайте диапазоны
- Не отслеживать фактические данные: Без истории оценки не улучшаются
Профессиональные Советы
Сравнивайте оценки с фактом. После каждого проекта анализируйте. Это повышает точность.
Добавляйте буфер на неизвестность. Для новых доменов: 20-30%. Для знакомых: 10-15%.
Представляйте диапазоны, не точки. «15-20 дней» честнее и полезнее, чем «17.3 дня».
Используйте Wideband Delphi для важных оценок. Когда оценка определяет бюджет или штат, привлекайте нескольких экспертов.
Оценивайте при планировании, не после. Если оцениваете после начала разработки, вы уже отстаёте.