Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про то, почему оценки трудозатрат в тестировании так часто разъезжаются с реальностью, и что с этим делают команды, которые научились попадать в сроки.

Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce и преподаю на курсах разработки и архитектуры в ОТУС.

---

За годы работы я пересмотрел много спринтов, где всё ломалось не на коде, а на цифре в поле «оценка». Разработчик говорит «тут на день», тестировщик молча кивает, а через неделю релиз висит, потому что регресс вскрыл три интеграции, о которых на планировании никто не вспомнил. И каждый раз это подаётся как «ну, не угадали». Хотя проблема не в угадывании. Проблема в том, что оценку вообще пытались угадать.

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

Какие это 7 ошибок

1. Оценивают код, а тестирование дописывают «сверху»

2. Оценивают одним числом там, где есть только диапазон

3. Забывают «невидимые» статьи трудозатрат

4. Оценивают в вакууме, без истории

5. Путают оценку с обязательством

6. Дробят задачу до бесконечности — или не дробят вовсе

7. Считают, что AI-инструменты сделают оценку ненужной

Почему «на глаз» — это не оценка, а ставка

Сначала договоримся о том, что вообще происходит, когда человек оценивает задачу «интуитивно».

Он берёт задачу, представляет happy path — как всё пройдёт, если ничего не сломается, — и называет время под этот идеальный сценарий. Проблема в том, что тестирование существует ровно для тех случаев, когда что-то ломается. То есть интуитивная оценка по определению описывает мир, в котором тестировать нечего.

Мне как-то попалась хорошая формулировка у команды aqua cloud (они делают инструмент для тест-менеджмента и обобщили опыт своих senior-тестировщиков): команды с кристально ясными требованиями стабильно попадают в свои оценки с точностью около 10% разброса, а расплывчатые user story не просто замедляют тестирование — они каскадом бьют по каждой переменной оценки. Это наблюдение, а не строгое исследование, но оптику оно задаёт верную: точность оценки определяется не талантом оценщика, а качеством того, что он оценивает. Если требование мутное, никакая интуиция его не спасёт.

Дальше — по ошибкам.

Небольшая оговорка перед стартом. Я для простоты оперирую оценками во времени — часами и днями, потому что речь про планирование тестирования и разговор с бизнесом идёт в сроках. Если ваша команда живёт в story points, всё описанное ниже остаётся в силе: меняется только единица оценки. И работает это одинаково что в Scrum, что в Kanban.

Ошибка 1. Оценивают код, а тестирование дописывают «сверху»

Симптом. В задаче стоит оценка разработки — «3 дня». А тестирование при обсуждении истории вообще не звучало: его как будто нет, оно случится «когда-нибудь потом». В Jira это выглядит так:

# (YAML: типовая карточка, где тестирование выпало из разговора)
task: PAY-1423
summary: "Добавить сортировку транзакций по сумме"
estimate: 3d              # заведена как чисто разработческая
acceptance_criteria:
  - "Транзакции сортируются по возрастанию суммы"
# про регресс, данные, окружение при оценке не сказали ни слова

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

Последствия. QA-работа становится невидимой, всплывает в конце спринта и съедает буфер, которого нет. Классика: скрытая работа, которая появляется в последний момент и рушит прогноз.

Как чинится. Оценка ставится на всю историю целиком, а не отдельными кусками «dev» и «QA». Это не моё частное мнение, а жёсткая позиция сообщества. Майк Кон (Mountain Goat Software) прямо отговаривает складывать «программистские» и «тестировщицкие» баллы: story point должен отражать полный объём усилий на историю, и суммирование баллов по навыкам мешает команде понимать работу друг друга. В Scrum-гайдовой логике то же: размер элемента бэклога учитывает всё, что нужно для Done, единой оценкой, потому что история сделана только тогда, когда протестирована и релизопригодна.

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

Ошибка 2. Оценивают одним числом там, где есть только диапазон

Симптом. Оценка выглядит как «2 дня». Одно число. Без вариантов.

Причина. Одно число психологически комфортнее: его проще назвать, проще занести в план, проще показать менеджеру. Беда в том, что комфорт и точность здесь тянут в разные стороны.

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

Как чинится. Оценка диапазоном вместо точки. Простейший рабочий инструмент — трёхточечная оценка (PERT): берём оптимистичный, наиболее вероятный и пессимистичный сценарии и считаем взвешенное среднее.

# (формула PERT, для справки)
Ожидаемое = (O + 4*M + P) / 6

# пример для задачи регресса:
O = 4h   (всё зелёное, ничего не всплыло)
M = 8h   (пара мелких багов, стандартный цикл)
P = 20h  (задели смежный модуль, нужен полный прогон)

Ожидаемое = (4 + 4*8 + 20) / 6 = 9.3h

Смысл не в арифметике, а в том, что вы проговариваете пессимистичный сценарий вслух. Трёхточечная оценка использует диапазон вместо одного числа и за счёт снижения влияния крайних значений даёт более надёжный прогноз на неопределённых задачах. Исторически PERT придумали для крупных проектов, а не отдельных тикетов — но, несмотря на происхождение, логика «оптимизм / реализм / пессимизм» масштабируется вниз без потерь и удобна для оценки отдельных задач тестирования. То самое P=20h — это не пессимизм ради пессимизма, а заранее названный риск, под который закладывают буфер.

У разрыва между «оптимистично» и «пессимистично» есть имя — конус неопределённости (cone of uncertainty). В начале, когда о задаче известно меньше всего, разброс максимальный и вилка широкая. По мере прояснения — уточнили требования, увидели код, прогнали первые проверки — конус сужается, и оценка становится точнее. Вывод один: оценка на старте обязана быть широкой. Требовать точную цифру, когда конус ещё максимально раскрыт, — значит требовать угадывания.

Ошибка 3. Забывают «невидимые» статьи трудозатрат

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

Причина. Эти активности не выглядят как «тестирование» в наивном представлении, поэтому не попадают в оценку. А по факту на них уходит существенная часть трудозатрат — иногда большая, чем на сам прогон кейсов.

Последствия. Оценка честно описывает верхушку айсберга и умалчивает про подводную часть. Порядок цифр показателен: по оценке DeviQA (подрядчик по QA, обобщает опыт своих проектов), сопровождение тестов съедает 30–40% усилий QA-команды в крупных организациях — каждое изменение UI, API или модели данных ломает десятки тестов не потому, что появился дефект, а потому что тесты устарели. Это наблюдение по их клиентской базе, а не константа, но направление верное: если этот пласт не заложить в оценку, он всё равно случится — просто за счёт ваших выходных.

Как чинится. Декомпозиция задачи на активности до того, как названо число. Хороший приём подсмотрел у команды MagicPod: они сначала разбивают историю на конкретные тестовые активности и только потом присваивают баллы. Их же пример показателен: разработчик оценил фичу сортировки в 3 балла как простую реализацию на готовых компонентах, а QA-инженер — в 8, потому что увидел тестирование совместимости с браузерами и устройствами, проверку пустого состояния и регресс затронутых страниц; в итоге сошлись на 5 после обсуждения.

Вот тот самый разрыв 3 против 8 — это не спор о том, кто прав. Это ровно та невидимая часть работы, которая всплыла только потому, что кто-то задал правильный вопрос. Мой рабочий чек-лист «а это заложили?» выглядит так:

Ошибка 4. Оценивают в вакууме, без истории

Симптом. Каждую оценку команда рожает заново, «с чистого листа», как будто похожих задач раньше не было.

Причина. Исторические данные не собираются или лежат мёртвым грузом в закрытых спринтах, куда никто не заглядывает.

Последствия. Команда раз за разом наступает на те же грабли и не учится на собственных промахах. А ведь эталон обычно лежит рядом.

Как чинится. Оценка от эталона — это то, что называют reference-class forecasting: вместо оценки «изнутри», от воображаемого хода работы, берём класс похожих задач из прошлого и смотрим, сколько они заняли по факту. Прежде чем спорить о числе, поднимаем аналогичную историю из прошлых спринтов и сверяемся с реальностью. Это отрезвляет быстрее любых формул. В обзоре aqua cloud это первым пунктом: опирайтесь на исторические данные прошлых проектов и советуйтесь с командой, чтобы увидеть подводные камни с разных сторон.

Одна оговорка, без которой совет неполный: эталон работает, пока команда примерно та же. Если состав сменился наполовину, история резко теряет силу — у новых людей другая скорость и другие слепые зоны. Тогда история годится как ориентир, а не как готовый ответ.

Здесь же живёт planning poker — не ритуал, а способ вытащить наружу расхождения. Каждый показывает карту, и если карты сошлись — отлично, а если нет, команда разбирает крайние оценки: и самую высокую, и самую низкую. Если один показал «3», а другой «13», ценность не в усреднении, а в том, чтобы услышать обоих: возможно, оптимист не знает про флаки-тесты, а пессимист — про готовый переиспользуемый набор проверок. Ценна не итоговая карта, а момент, когда тестировщик объясняет, почему у него не «3», а «8».

Вот как это выглядит как процесс, к которому я прихожу с командами. Ниже — схема на рис. 2: путь одной задачи от прихода в бэклог до обновления эталонной базы.

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

Ошибка 5. Путают оценку с обязательством

Симптом. Оценка, названная на планировании, мгновенно превращается в дедлайн, который «нельзя двигать».

Причина. Менеджменту нужна определённость, и оценка — ближайшее, что на неё похоже. Её и хватают.

Последствия. Команда начинает защищаться: закладывает скрытые буферы, завышает числа, лишь бы не подставиться. Оценки раздуваются, доверие падает, планирование превращается в торг. У Atlassian это сформулировано жёстко: оценка в story points — это оценка, а не клятва на крови; нет требования работать в выходные, чтобы компенсировать недооценку, и баллы ломаются, когда их используют, чтобы судить людей и назначать детальные сроки.

Как чинится. Разделять две вещи в коммуникации: оценку (наше текущее понимание объёма) и обязательство (что мы готовы вынести наружу как срок). Оценка живёт внутри команды и уточняется. Обязательство даётся с буфером и с явно проговоренным диапазоном. В этой ситуации я бы всегда показывал менеджеру не точку, а вилку «от–до» с указанием, от чего зависит верхняя граница — так разговор идёт про риски, а не про то, «почему вы не угадали».

На практике я оформляю это прямо в карточке — чтобы обязательство и его условия было видно всем, а не жили в голове у Lead:

# (YAML: как оценка попадает в задачу, чтобы её не прочитали как дедлайн)
task: PAY-1487
estimate_range: "1.5d – 4d"        # вилка, а не точка
commitment_external: "4d"          # что говорим наружу, с буфером
range_drivers:                     # от чего зависит верхняя граница
  - "нужен ли полный регресс оплаты"
  - "готовы ли тестовые данные по 3D-Secure"
  - "доступность стенда интеграции с банком"

Ключевое здесь — поле range_drivers. Пока названо, от чего зависит верхняя граница, разговор с менеджером идёт про конкретные риски, которые можно снять, а не про абстрактное «долго».

Ещё один приём зрелых команд — говорить об оценке в терминах уверенности. Не «сделаем за 3 дня», а «процентов на 80 уложимся в 3 дня, для 95% нужен запас до 4». Непривычно для менеджмента, зато честно: вы сразу показываете, что оценка вероятностная, и переводите разговор из «обещал / не обещал» в «какой уровень риска принимаем».

Ошибка 6. Дробят задачу до бесконечности — или не дробят вовсе

Симптом. Две крайности. Либо в спринт берут монолит «протестировать модуль оплаты» без деталей, либо оценку дробят на получасовые микрозадачи, на ведение которых уходит больше времени, чем на саму работу.

Причина. В первом случае задачу не успевают декомпозировать и берут как есть, во втором — работает иллюзия, что чем мельче нарезка, тем точнее прогноз.

Последствия. Гигантскую задачу невозможно оценить с приемлемой точностью. Ориентиры у команд разные: у Atlassian встречается правило не брать элементы крупнее 16 часов, кто-то держит предел в день, кто-то в неделю — зависит от каденса и длины итерации. Смысл один: должен быть верхний предел, за которым оценка перестаёт быть надёжной; многие берут 1–2 рабочих дня на элемент. А переусердствовать с дроблением — значит утонуть в микроменеджменте, где накладные расходы съедают выгоду от точности.

Как чинится. Резать историю до testable-кусков, каждый из которых закрывает понятную часть риска, но не мельче. Ориентир — тот самый верхний предел в 1–2 дня на элемент: если задача больше, дробим; если куски уже по паре часов и их десятки, останавливаемся.

Вот как выглядит «протестировать модуль оплаты» после нормальной нарезки — каждый кусок оценивается отдельно, но все живут внутри одной истории:

# (YAML: монолит разбит на testable-куски под оценку)
story: "Тестирование модуля оплаты"
testable_slices:
  - name: "Успешная оплата картой (happy path)"
    estimate: "3h – 5h"
  - name: "Отклонённые платежи и таймауты банка"
    estimate: "4h – 8h"
  - name: "3D-Secure и повторные списания"
    estimate: "6h – 12h"      # самый рискованный кусок
  - name: "Регресс истории транзакций"
    estimate: "2h – 4h"
# каждый кусок укладывается в 1-2 дня; сумма даёт честную вилку по истории

Как это описывают практики: большую историю бьют на тестируемые части и переоценивают, если в ходе работы всплыли усложнения, а не пытаются угадать всё до старта. Обратите внимание: самый узкий по времени кусок (happy path) и самый рискованный (3D-Secure) сразу видно — и именно на второй закладывается буфер.

С этой ошибкой хорошо борется Definition of Ready — договорённость о том, что задача вообще готова к оценке. Если непонятны требования, не готовы тестовые данные или не ясны критерии приёмки — она ещё не Ready, и оценивать её значит гадать. Простой DoR перед оценкой отсекает половину будущих промахов: нельзя надёжно оценить то, что толком не сформулировано.

Ошибка 7. Считают, что AI-инструменты сделают оценку ненужной

Это самая свежая ошибка — и в 2026 году я вижу её всё чаще.

Симптом. «Зачем оценивать регресс, у нас же AI-прогон, он всё сам». Оценку трудозатрат негласно списывают, полагаясь на то, что автоматизация с самовосстановлением закроет вопрос.

Причина. AI действительно сильно ускорил исполнение тестов, и это создаёт обманчивое чувство, что человеческая оценка и надзор больше не нужны.

Последствия. Вот здесь хочу привести боевой кейс, который отлично показывает цену этой иллюзии. Это единичная история одной команды из разбора Logic Providers — не отраслевая статистика, а конкретный проект, но именно поэтому она наглядная. Команда вела большой SaaS-проект: больше 2500 Selenium-тестов, где каждое обновление фронтенда ломало десятки скриптов из-за нестабильных XPath-локаторов, регресс шёл больше 6 часов, сыпались ложные падения, и в какой-то момент поддержка автоматизации стала дороже написания новых тестов. Они внедрили AI-платформу с self-healing, и метрики в этом конкретном проекте полетели вверх: регресс сократился с 6 часов до 2,5, а сопровождение — примерно на 40%. Повторюсь: это цифры одного кейса, у другой команды они будут свои.

Звучит как успех. Но вот та часть, ради которой я эту историю рассказываю. Self-healing — механизм, который автоматически «чинит» упавший тест, подстраивая его под изменившийся интерфейс. Сразу оговорюсь, чтобы не свалиться в модное «AI — это опасно»: опасен не сам механизм self-healing, а его применение без контроля изменений и человеческой валидации.

Сам по себе он полезен, проблема начинается там, где на него полагаются вслепую. В разборе DeviQA это сформулировано точно: self-healing — это средство снижения затрат на поддержку, а не стратегия тестирования; когда AI молча адаптирует тест, чтобы тот прошёл после изменения приложения, команда теряет видимость того, было ли это изменение намеренным или это регрессия под маской. Без надзора самовосстановление снижает надёжность тестов, а не повышает её. То есть тест переписался под сломанный UI, отчёт стал зелёным, а баг уехал в прод. Могу себе представить, как такой зелёный отчёт усыпляет команду ровно до звонка от пользователей.

Ниже на рис. 3 — как выглядит этот разрыв между «стало быстрее» и «стало надёжнее».

Как чинится. AI не отменяет оценку, а меняет её предмет. Раньше оценивали часы на прогон — теперь оцениваем время на надзор: проверку того, что self-healing «починил», разбор адаптированных тестов. Индустрия сходится на гибридной модели: AI берёт широту покрытия и рутинный регресс, а человек — доменно-критичные сценарии и поиск пограничных случаев.

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

Сводная таблица: ошибка → признак → что проверить

Какой навык на самом деле проверяет эта группа ошибок

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

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

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

Больше об управлении тестированием читайте в выпусках:

• Процесс тестирования: от анализа до завершения

• Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)

Когда оценки раз за разом расходятся с фактическими трудозатратами, проблема обычно скрыта в самом подходе к планированию. На бесплатном уроке курса «Руководитель группы тестирования (QA Lead)» 21 июля в 20:00 будет разбор, как оценивать отдельные задачи QA и учитывать риски, чтобы выстроить управляемую работу команды и перестать воспринимать срывы сроков как неизбежность. Участвовать.

Больше бесплатных уроков июля смотрите в дайджесте.