«Сколько времени займёт тестирование?» - один из самых частых вопросов при планировании разработки.

Ответить на него сложнее, чем кажется. За одним вопросом обычно скрываются сразу несколько: сколько работы предстоит выполнить, когда команда сможет её сделать и успеет ли она к нужной дате.

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

Поэтому начинать стоит с разделения трудозатрат, прогноза срока и дедлайна.

Предположим, тестирование изменения требует около 40 человеко-часов.

Это оценка объёма работы. Она не означает, что тестирование закончится через пять рабочих дней.

У инженера могут быть другие задачи, поддержка релиза и встречи. Часть проверок нельзя начать до появления сборки, а после обнаружения дефекта придётся дождаться исправления и провести повторную проверку.

Поэтому полезно различать:

Трудозатраты - сколько работы необходимо выполнить.

Прогноз срока - когда эта работа, скорее всего, будет завершена с учётом загрузки команды и зависимостей.

Дедлайн - дата, к которой результат нужен бизнесу.

Если прогноз не помещается в дедлайн, уменьшать оценку бессмысленно. Нужно менять объём, ресурсы, срок или принимаемый риск.

Одна из частых ошибок - считать только время непосредственного выполнения тестов.

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

Но работа QA может включать не только выполнение проверок:

• анализ требований и изменений;
• подготовку данных и окружения;
• проектирование проверок;
• исследовательское тестирование;
• анализ логов;
• оформление дефектов;
• повторные проверки;
• регрессию затронутой функциональности.

Если эти активности связаны с конкретной задачей, их нужно учитывать в её трудозатратах.

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

Для небольшой и хорошо знакомой задачи подробная декомпозиция может быть избыточной. Но для крупной или новой функциональности полезно сначала ответить на несколько вопросов:

1. Что именно изменяется?
2. Какие компоненты и пользовательские сценарии затронуты?
3. Какие виды тестирования потребуются?
4. Какие платформы и конфигурации нужно проверить?
5. Какие данные и окружения понадобятся?
6. Какой объём регрессии возможен?
7. Какие зависимости и неизвестные остаются?

После этого становится понятнее не только количество работы, но и основные источники неопределённости.

Если команда уже тестировала похожие изменения, лучше всего начать с фактических данных.

Важно сравнивать не названия задач, а факторы сложности. Две интеграции с платёжными системами могут отличаться количеством сценариев, числом платформ, качеством тестового стенда или необходимостью проверять возвраты.

Для новой или крупной функциональности работу можно разбить на части и оценить их отдельно.

При высокой неопределённости полезнее использовать диапазон, чем одно число. Но диапазон должен иметь объяснение.

Фраза: «Потребуется 40–50 часов» сама по себе мало что даёт. Гораздо полезнее: «Тестирование аналогичных изменений обычно занимает около 40 часов, но сейчас не готов тестовый стенд и неизвестен окончательный объём регрессии, поэтому для планирования используем диапазон 40–50 часов.»

Здесь понятны и основание оценки, и причина неопределённости.

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

После оценки трудозатрат начинается планирование.

Допустим, команда понимает, сколько работы осталось. Теперь нужно определить, кто и когда сможет её выполнить.

Если QA почти полностью занят этой задачей, срок будет одним. Если половину времени он должен поддерживать другой релиз - другим.

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

На календарный срок также влияют внешние зависимости:

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

Эти факторы могут увеличить длительность тестирования, хотя сами по себе не являются дополнительными трудозатратами QA.

Отсюда и важное правило: оценка объёма работы и прогноз даты завершения - связанные, но разные вещи.

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

Можно:

• уменьшить объём функциональности релиза;
• сократить объём проверок и принять дополнительный риск;
• добавить инженеров там, где работу действительно можно распараллелить;
• пересмотреть дату релиза.

Добавление людей помогает не всегда. Два QA могут параллельно проверять разные платформы, но не смогут быстрее дождаться новой сборки или исправления блокирующего дефекта.

Поэтому задача лида - не заставить оценку совпасть с дедлайном, а показать ограничение и предложить варианты.

Любая оценка строится на информации, доступной в момент планирования.

Во время работы появляются новые данные: уточняется реализация, обнаруживаются дефекты, меняется объём регрессии, возникают блокировки.

В таком случае не нужно заново оценивать уже выполненную работу. Нужно оценить оставшийся объём и обновить прогноз завершения.

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

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

После завершения задачи полезно сравнить ожидания с фактом и понять причину отклонения: забыли часть работы, изменился объём, долго ждали сборку, потребовалось больше регрессии или задача оказалась не похожа на выбранный аналог.

Так постепенно появляется статистика, на которую можно опираться при следующих оценках.

При этом точность первоначальной оценки не стоит использовать как KPI отдельного инженера. Иначе появляется мотивация не точнее прогнозировать, а оставлять больший запас.

При оценке новой задачи можно идти последовательно:

1. Определить, что именно изменяется.
2. Зафиксировать, что входит и не входит в тестирование.
3. Найти зависимости и неизвестные.
4. При необходимости декомпозировать работу.
5. Оценить трудозатраты, опираясь на опыт и исторические данные.
6. Определить доступность команды.
7. Сформировать прогноз срока.
8. Обновить его, если изменились исходные условия.

Оценка не должна гарантировать идеальное попадание в дату. Её задача - дать команде достаточно информации, чтобы понимать объём работы, ограничения и риски и вовремя принимать решения.

Хороший процесс - это не тот, в котором прогноз никогда не меняется, а тот, в котором команда понимает, почему он изменился и что с этим делать.

Обсудить статью можно в канале «Тестировщики нужны» — в Telegram, MAX и Сетке.