Ответ
Для точной оценки временных затрат в тестировании применяю комбинацию методов:
1. Экспертная оценка
- Основана на опыте и исторических данных по аналогичным задачам.
- Пример: "Тестирование REST API эндпоинта займет ~3 часа".
2. Разбивка на подзадачи (Work Breakdown Structure)
- Декомпозиция задачи на мелкие, оцениваемые этапы.
- Анализ требований: 0.5ч
- Написание тест-кейсов: 1ч
- Выполнение тестов: 1.5ч
- Подготовка отчета: 0.5ч
- Итого: 3.5ч
3. PERT-анализ (Program Evaluation and Review Technique)
- Используется для задач с высокой неопределенностью.
- Формула:
(Оптимистичная + 4 * Наиболее вероятная + Пессимистичная) / 6 - Пример: (2ч + 4*4ч + 10ч) / 6 = 4.67 часа.
4. Тайм-трекинг и анализ прошлых задач
- Использую данные из Jira, Toggl для калибровки будущих оценок.
Ключевые факторы для уточнения оценки: сложность фичи, зависимость от других команд, наличие тестовых данных и окружения.
Ответ 18+ 🔞
Давай я тебе на пальцах, без этих ваших заумных методичек, объясню, как я время на тестирование прикидываю. А то смотришь на задачу и думаешь: "Ну, часок, полтора, и в баню". А потом хуяк — и неделю в ней ковыряешься, потому что выяснилось, что бэкенд-то пишет не в ту таблицу, а фронтенд рисует хуй пойми что.
1. Метод "На глазок", или "Экспертная оценка" Это когда смотришь на задачу и из жопы цифру вытаскиваешь. Но не просто так, а на основе того, что уже десять таких же накосячил. Типа: "Тестирование одного API-метода? Ну, часа три, если дебилов нет". Ключевое — "если дебилов нет". А они, сука, всегда есть.
2. Метод "Раздробить на кусочки, чтобы не охуеть" Берёшь эту, с виду простую, хуйню и начинаешь её на части рвать. А то в кучу всё — и пиздец, непонятно, где время утекает.
- Глянуть, что от меня хотят (требования): 30 мин (а если их нет, то +2 часа на выяснение отношений).
- Написать чек-лист, что тыкать: 1 час.
- Непосредственно потыкать и всё сломать: 1.5 часа.
- Оформить баг-репорты такие сочные, чтобы разработчик аж вспотел: 1 час.
- Итого по минимуму: 4 часа. А теперь умножь на коэффициент "внезапной хуйни", который равен 1.5.Вот так из "часика" внезапно получается почти рабочий день, ёпта.
3. Метод "PERT-анализ", или "От пессимиста до оптимиста" Применяю, когда задача пахнет жареным и непонятно, что там под капотом. Считаем по волшебной формуле.
- Оптимистично (все работают, багов нет, я выспался): 2 часа.
- Реалистично (как обычно): 4 часа.
- Пессимистично (всё сломалось, нужны данные, которых нет, завис билд, а тимлид в отпуске): 2 рабочих дня (16 часов).
Считаем: (2 + 4*4 + 16) / 6 = 5.67 часа. Вот видишь? "На глазок" было 3, а по факту — почти 6. Вот где собака-то, сука, порылась.
4. Метод "Посмотреть, как я уже проёбывался раньше" Это самое ценное. Открываю Jira, смотрю на похожие старые таски и вижу: "Ага, 'тестирование платежа' в прошлый раз заняло не 3 часа, а 8, потому что тестовый стенд падал". Вот это и есть калибровка, блядь. Без истории — ты слепой, просто пальцем в небо тычешь.
На что ещё смотреть, чтобы не обосраться с оценкой:
- Сложность: Это новая хуйня или старый, обкатанный функционал?
- Зависимости: Мне нужно ждать, пока Вася из соседнего отдела свою часть сделает? Если да, то смело прибавляй 50% ко времени просто на ожидание и координацию.
- Данные и окружение: Есть ли тестовые данные? А если найду? Стенд стабильный или он, как обычно, "чуть-чуть подтормаживает" (читай: падает раз в час)?
Короче, суть в чём: чтобы не выглядеть идиотом, никогда не давай одну цифру. Давай диапазон: "От 4 до 8 часов, потому что если с данными всё ок — быстро, а если нет — будет боль и страдание". И все будут довольны, и тебя потом не пошлют нахуй за срыв сроков.