«Сколько займёт тестирование?» — как давать оценку и не закапывать себя

Конец планирования, все уже подустали, и тут PM поворачивается: «А тестирование сколько займёт?» И ты говоришь «ну, дня два» — с потолка, быстро, чтобы не выглядеть тем, кто тормозит митинг. Дальше два сценария, оба плохие: либо сидишь вечерами, дотягивая реальность до своей цифры, либо объясняешь, почему «обещал два дня, а тестируешь четвёртый».

Самое обидное — цифра, которую ты назвал за три секунды, живёт потом недели. Она попадает в план релиза, в ожидания стейкхолдеров, и когда что-то идёт не так, разговор начинается с неё: «ты же сам сказал два дня». Расскажу, как я перестал называть цифры с потолка — и что говорю вместо этого.

Почему оценка тестирования — особый жанр

Разработчик оценивает свою работу: вот задача, вот код, который надо написать. У QA всё хуже: мы оцениваем качество чужой работы, которой ещё не существует.

Сколько времени займёт тестирование фичи, зависит не столько от фичи, сколько от того, в каком состоянии она приедет. Придёт чистая — уложишься за день. Придёт с десятком багов — и ты не тестируешь, а крутишься в цикле «баг → фикс → ретест → новый баг». Сколько будет багов, ты не знаешь. Сколько итераций фиксов — тоже. То есть честный ответ на «сколько займёт тестирование?» — «зависит от того, что вы мне отдадите». Но такой ответ никого не устраивает, поэтому нужен способ давать цифру, не подписываясь под чужими рисками.

Эстимейт — это прогноз с допущениями, а не обещание

Главное, что я для себя поменял: перестал произносить цифру отдельно от допущений. Не «два дня», а «два дня, если билд придёт в среду, если фикс-итераций будет не больше двух, если платёжку не трогали». Цифра без допущений — это подпись под рисками, которыми ты не управляешь.

У Мартина Фаулера есть хорошая заметка о смысле оценок: оценка нужна не чтобы угадать будущее, а чтобы принять решение. Команде не нужна «правильная» цифра — ей нужно понять, успеваем ли к дате, что резать, где риск. Как только смотришь на эстимейт так, страх «ошибиться» отпускает: ты не гадалка, ты даёшь бизнесу данные для решения.

Декомпозиция вместо одной цифры

«Тестирование фичи» — неоцениваемая сущность, слишком крупная. Я раскладываю на части, которые оцениваются по отдельности:

подготовка: тест-кейсы, тестовые данные, стенды, доступы;
первый прогон новой функциональности;
регресс вокруг — что фича могла зацепить;
ретесты багфиксов — та часть, которую забывают чаще всего;
автоматизация, если она входит в объём.

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

И вторая опора — история. Лучший предиктор — не интуиция, а прошлый похожий релиз: сколько он занял по факту, не по памяти (память врёт в оптимистичную сторону), а по трекеру. Если похожая фича в прошлый раз заняла четыре дня с двумя итерациями фиксов — с чего бы этой занять два?

Три точки вместо одной

Когда неопределённость большая, я вместо одной цифры даю вилку: оптимистичная оценка (всё чисто с первого раза), реалистичная (обычное количество багов и итераций) и пессимистичная (билд с опозданием, багов много, затронуто больше, чем казалось). Это классическая трёхточечная оценка — есть даже формула PERT (O + 4M + P) / 6, но формула тут не главное. Главное — вилка честно сообщает неопределённость, которую одна цифра прячет. «От двух до пяти дней, скорее всего три» говорит команде гораздо больше, чем уверенное «три дня», после которого четвёртый день выглядит как твой провал.

Буфер: не «×2 на всякий случай», а именованные риски

Все знают трюк «посчитай и умножь на два». Проблема в том, что анонимный буфер режут первым: «а почему тут так много? давайте ужмём». И правильно делают — необоснованная цифра не защищается.

Поэтому буфер у меня всегда именованный: «+день, если билд приедет позже среды», «+полдня, если правки заденут платёжный флоу», «+день на вторую итерацию фиксов, по прошлому релизу она была». Именованный риск нельзя молча вычеркнуть — его можно только осознанно принять: «окей, билд точно будет в среду, этот день убираем». Отлично, это уже не урезание оценки, это снятие риска — совсем другой разговор.

Когда время режут

А его будут резать. «Два дня на тестирование нет, есть один» — знакомо. Тут две ловушки: молча согласиться (и принять на себя весь риск) или встать в позу «тогда я ни за что не отвечаю» (и испортить отношения).

Я делаю иначе — торгуюсь объёмом, а не качеством: «За один день я успею проверить оплату и основной сценарий. Локализация и edge-кейсы останутся непроверенными — если там что-то всплывёт на проде, узнаем от пользователей. Принимаем этот риск?» И дальше ключевое: решение о принятии риска — это решение бизнеса, а не моё, и оно должно быть письменным. Одно сообщение в канале релиза: что проверено, что нет, какой риск, кто принял решение. Не для того, чтобы потом тыкать носом, а чтобы решение о риске принимал тот, кто им управляет — осознанно, а не по умолчанию на плечах QA. Как формулировать такие вещи без паники и обиды — я разбирал в посте про bad news стейкхолдерам.

Антипаттерны, через которые я прошёл

Цифра с потолка, чтобы выглядеть уверенно. Уверенность продержится до первого сорванного срока, а репутация «называет сроки и не попадает» — это худшее, что может быть у QA в глазах команды. Как ни парадоксально, «мне нужно полчаса посмотреть требования, потом скажу» звучит профессиональнее мгновенного «два дня».

Молчаливое «ок» на урезание. Если время урезали, а объём и риски не переоценили — ты только что молча взял чужой риск себе.

«Тестирование закончится, когда закончатся баги». Звучит принципиально, но это не оценка, а отказ от разговора. Баги не закончатся никогда — правильный ответ живёт в плоскости exit-критериев: что должно быть проверено и что должно не падать, чтобы релиз выпускать.

Путать «я потрачу три дня» и «будет готово через три дня». Три дня чистой работы превращаются в неделю календаря: ожидание билда, ожидание фиксов, параллельные задачи, у разработчика спринт-ревью. Спрашивают обычно про календарь — а отвечаем мы часто про effort. Проговаривай, что именно называешь.

Оценка до того, как увидел требования. «Примерно сколько?» на фичу из одного заголовка — это гадание. Минимум, который стоит выторговать: полчаса на прочитать требования и задать два вопроса. Оценка после этого будет другой — и твоей.

Чек-лист перед тем, как назвать цифру

Я видел требования, а не только заголовок задачи
Оценка разложена: подготовка / первый прогон / регресс / ретесты фиксов
Итерации багфиксов заложены явно (по истории команды, не по надежде)
Есть похожий прошлый релиз для сверки — смотрел факт в трекере, не память
Вместо одной цифры — вилка или цифра с допущениями
Буфер именованный: какой риск, сколько стоит
Понятно, что называю: effort или календарный срок
Если время урежут — знаю, что выпадет из объёма и кто примет риск

Цифра, которую ты назвал, — единственное, что все услышат и запишут. Допущения, при которых она верна, — единственное, что тебя потом спасёт. Называй их только вместе.