Пятница, 17:00. Я смотрю на доску с задачами и говорю тимлиду: «Всё, я закрыл автотесты». Он подходит, смотрит на план спринта и говорит: «Мы договаривались закончить в среду».

Почему мы так часто ошибаемся в оценке

Автотесты обманчивы. Снаружи кажется: «просто написать пару assert’ов». Внутри за ними всегда скрываются настройка окружения, подготовка данных, отладка на CI и неизбежные флаки. Если вы не заложили это в оценку, сроки гарантированно поплывут.

Правило №1. Декомпозируйте до атомарного действия

Оценка крупной задачи — бесполезное занятие. Вы не можете адекватно оценить «Написать тесты для модуля авторизации». Вы можете оценить: «Создать фикстуры для мока токена», «Прописать негативные сценарии для невалидного пароля», «Запустить тест локально и убедиться в его прохождении», «Прогнать на CI и проверить инфраструктурные таймауты».

В идеале каждая подзадача занимает не больше 4 часов. Если больше — режьте снова. Это ваш основной инструмент контроля.

Правило №2. Каждая задача имеет свой «вес» риска

Вы делите работу на шаги. Теперь оценивайте каждый шаг не по времени, а по степени неопределённости. Если вы впервые работаете с API этого сервиса, добавьте к оценке +50%. Если CI падает каждый второй прогон, добавьте +30% на прогон и перезапуски.

Кейс из моей практики

Пару месяцев назад я взял задачу: написать автотест для эндпоинта выгрузки отчётов. Посмотрел на описание, прикинул структуру JSON, сказал: «Два дня».

На третий день я понял, что забыл про логику работы с датами. На четвёртый день выяснилось, что тестовые данные нужно подготавливать через базу, а не через API. На пятый день тесты на CI упали из-за разницы часовых поясов.

В итоге я потратил 5 дней вместо 2. Всё из-за того, что я посмотрел на задачу как на монолит, а не разбил её на кирпичики.

Зеркало. Разрушаем миф

Многие думают: «Оценка автотестов — это просто предсказание». На практике это процесс управления неизвестностью. Вы не можете быть уверены на 100%. Но вы можете снизить процент ошибки, если станете разбивать задачу на маленькие кусочки и честно признавать риски перед командой.

Как я теперь делаю, чтобы не промахнуться

Я беру чистый лист. Выписываю каждое действие, необходимое для запуска теста: написание кода, создание фикстур, проверка локально, интеграция в CI, обработка возможных ошибок. Каждому пункту ставлю вес в часах. Затем суммирую, добавляю буфер на гонку данных и внезапные сбои.

В итоге я получаю реалистичную цифру. И прихожу не с «наверное, 2 дня», а с «три часа на код, час на данные, час на CI, плюс два часа на случайности. Итого 8 часов».

План помогает команде планировать спринты без нервов.