Может там работы на: 15 мин - поговорить с developers, 15 мин - написать mini-spec/checklist, и 2 часа на тестирование.
dodging the issue doesn't help to resolve the issue.
По поводу 2 часов. Чем меньше проект - тем легче оценить время. Если программа класса "Hallo word!", то нормальной оценкой будет: "Сегодня закончу".
Для, хотя бы, среднего проекта (от 100 человекомесяцев) все по-другому. Еще большую неопределенность вносит принадлежность проекта к определенному классу (вернее отсутствие информации о классе проекта).
Пример.
Есть проект. Около 500 прецедентов. 30 человекомесяцев кодирования. Больше ничего неизвестно. Сколько времени нужно на тестирование?
1. Простой проект. Требований к безопасности, конкурентой работе, дальнейшей поддержке и т.д. нет. Ошибки при работе программы приводят к неудобству пользователя.
Вполне может хватить одного человеко месяца. Ошибка в оценке запрошенного времени тестирования некритична.
2. Добавляем требования:
* Работа в разных окружениях.
* Безопасность и права доступа.
* Конкурентную работу.
* Жесткие требования к юзабилити.
* И т.д.
Временные затраты резко пошли вверх. Это уже 10-20 человекомесяцев.
Но ошибка в оценке запрошенного времени тестирования по-прежнему некритична.
3. Изменим класс проекта. Пусть теперь пропущенная ошибка приводит не к "неудобству пользователя", а "всего лишь" к огромным финансовым потерям. Классический пример - потеря ракетоносителя с дорогостоящим оборудованием. Но мы возьмем другой пример.
Разработана программа для микропроцессора. Разработана "впритык". Исправление ошибки может привести к выходу за пределы данного микропроцессора. Если она обнаружится после крайнего срока, то это: переход на другой процессор (уже закупленные оставляем на складе), выкидывание уже изготовленных плат и т.д..
В этом случае я не буду подписываться под словами "2 часа", без тщательного изучения документации.
PS. Пример взят из неплохого рассказа
Истоpия одного байта.