7 ошибок в оценке QA-задач, из-за которых команда срывает сроки релиза

В сфере искусственного интеллекта произошло заметное событие. sproshchaev 8 минут назад 7 ошибок в оценке QA-задач, из-за которых команда срывает сроки релиза Средний 13 мин 354 Блог компании OTUS Тестирование IT-систем * Управление проектами * Управление разработкой * Карьера в IT-индустрии Туториал Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про то, почему оценки трудозатрат в тестировании так часто разъезжаются с реальностью, и что с этим делают команды, которые научились попадать в сроки. Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce и преподаю на курсах разработки и архитектуры в ОТУС. За годы работы я пересмотрел много спринтов, где всё ломалось не на коде, а на цифре в поле «оценка».

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

Технические детали

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

Для каждой покажу симптом, причину, последствия и то, как это чинится в командах, которые к июню 2026 года уже перестроили процесс. Какие это 7 ошибокОценивают код, а тестирование дописывают «сверху»Оценивают одним числом там, где есть только диапазонЗабывают «невидимые» статьи трудозатратОценивают в вакууме, без историиПутают оценку с обязательствомДробят задачу до бесконечности — или не дробят вовсеСчитают, что AI-инструменты сделают оценку ненужнойРис. Разрыв между оценкой «на глаз» и реальными трудозатратами на тестированиеПочему «на глаз» — это не оценка, а ставкаСначала договоримся о том, что вообще происходит, когда человек оценивает задачу «интуитивно».

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

Отраслевые последствия

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

Небольшая оговорка перед стартом. Я для простоты оперирую оценками во времени — часами и днями, потому что речь про планирование тестирования и разговор с бизнесом идёт в сроках.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.