Оценка трудозатрат в тестировании: методы и пример расчёта

Что такое эстимация и зачем она нужна

Эстимация (от английского estimation) – это оценка трудозатрат: сколько часов, дней и людей понадобится на тестирование. Глоссарий ISTQB определяет оценку тестирования как расчётное приближение, которым можно пользоваться, даже когда исходные данные неполны или неточны. Оценивают не только время, но и дату завершения, стоимость и число тест-кейсов.

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

Целей у оценки несколько.

• Сроки

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

• Бюджет и модель оплаты

  При модели fixed price сумма известна заранее, а объём работ оговаривают на берегу: сколько будет тестировщиков, будет ли автоматизация. Добавить по ходу, скажем, нагрузочное тестирование уже нельзя, поэтому fixed price выбирают для небольших проектов, где объём не изменится. При модели time and material итоговая стоимость заранее неизвестна и объём можно расширять, и сейчас её выбирают гораздо чаще, особенно в гибкой разработке. В обоих случаях оценка говорит заказчику, сколько продлится тестирование и сколько понадобится людей.

• Оптимизация работы

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

Методы оценки трудозатрат

Методик много. Ниже шесть распространённых, от самых точных до самых грубых.

• Декомпозиция и оценка по тест-кейсам

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

• Оценка по трём точкам (PERT)

  Берут оптимистичный, наиболее вероятный и пессимистичный срок и сводят их формулой. Вместе с оценкой по тест-кейсам это самый точный из шести методов.

• От времени разработки

  Время, которое насчитали разработчики, умножают на 30 или 50%. Процент зависит от того, сколько разработчиков приходится на одного тестировщика: при трёх берут около 30%, при двух около 50%. Оценка очень грубая, и к ней прибегают, когда горят сроки и точность не нужна.

• На основе опыта

  Если в прошлую итерацию на тестирование ушло 100 часов, а бэклог текущей похож по объёму, закладывают те же 100 часов. Метод работает в почти лабораторных условиях, когда в команде те же люди с тем же опытом и на проекте ничего не меняется.

• "Палец в небо"

  Тестировщик на встрече говорит, что на одну фичу уйдёт три часа, а на другую пять. Опирается он только на собственный опыт, и к точным методам это отношения не имеет. Но в компаниях, где оценок не ведут вовсе, такого ответа бывает достаточно.

• Процентное распределение

  Каждому этапу жизненного цикла разработки отводят долю времени, например 30% на разработку, 20% на тестирование и 10% на анализ и сбор требований. Долю тестирования затем так же делят между этапами цикла тестирования (STLC): анализом требований, написанием тестовой документации и прогоном.

Оценка по тест-кейсам: пример расчёта

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

Результат удобно вести в таблице декомпозиции работ (work breakdown structure, WBS), шаблон которой я беру с сайта Guru99. На первом уровне стоит фаза или требование, под ним задачи-проверки, которые дробят дальше, пока есть что дробить. В соседних колонках пишут, кому назначена задача, когда начата и закончена, и комментарии. Полезно засекать, сколько времени уходит на кейсы, баг-репорты, ретесты и общение с командой: с такой базой следующая оценка выйдет точнее.

Дальше считают по шагам. Числа взяты из примера в уроке.

• 1. Тест-кейсы

  Декомпозиция дала 30 кейсов. На написание одного уходит около 10 минут и примерно столько же на прогон, всего 30 × (10 + 10) = 600 минут.

• 2. Баг-репорты

  Число дефектов предполагают по опыту и сложности функции. В простом интерфейсе их немного, в сложной бизнес-логике больше. В примере заложено 20% от числа кейсов, то есть 6 дефектов. Баг-репорт пишется примерно столько же, сколько тест-кейс, потому что шагов в нём похожее число, а функция уже знакома: 6 × 10 = 60 минут.

• 3. Ретесты

  Обычно закладывают, что после первого исправления половину багов переоткроют, а из переоткрытых ещё половину. В сумме ретестов выходит примерно вдвое больше, чем дефектов: 6 × 2 × 10 = 120 минут.

• 4. Риски и дополнительная работа

  Общение с командой, правка кейсов после разговора с разработчиком, ревью кейсов коллегой, подготовка сборок, встречи. На всё это обычно берут 30% от основной работы: (600 + 60 + 120) × 0,3 = 780 × 0,3 = 234 минуты.

• 5. Итог

  780 + 234 = 1014 минут, то есть примерно 17 часов на полное тестирование функции с учётом рисков. Это число передают менеджменту или вносят в общую оценку проекта.

Оценка по трём точкам (PERT)

Метод берёт три оценки одной и той же работы. Оптимистичная (O) предполагает, что ничто не помешает. Пессимистичная (P) учитывает, что всё сложится плохо, например заболеет один из двух тестировщиков. Наиболее вероятная (M) лежит между ними, когда сработала часть рисков. В глоссарии ISTQB метод называется three point estimation.

Ожидаемый срок считают по формуле E = (O + 4M + P) / 6: наиболее вероятной оценке дают вес 4, и сумма делится на шесть частей. Стандартное отклонение SD = (P - O) / 6 показывает разброс, и в итоговую оценку пишут E ± SD.

Числа для формулы берут из той же оценки по тест-кейсам. В моём примере оптимистичная оценка – это основная работа без рисков, 780 минут, или 13 часов. Наиболее вероятная оценка равна той же работе с 30% на риски, около 17 часов. Пессимистичную, на случай болезни одного из тестировщиков, берут в 20 часов.

E = (13 + 4 × 17 + 20) / 6 ≈ 16,8 часа, SD = (20 - 13) / 6 ≈ 1,2 часа. В документ пишут 16,8 ± 1,2 часа, то есть от 15,6 до 18 часов, и результат почти совпадает с оценкой по тест-кейсам.

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

Что влияет на оценку по ISTQB

Программа ISTQB Foundation Level 2018 года делит методы оценки на две группы. Методы на основе метрик опираются на данные прошлых проектов или типовые значения, например на диаграммы сгорания в гибкой разработке. Экспертные методы опираются на опыт людей, и пример здесь – покер планирования (planning poker), где команда оценивает задачи картами.

На планировании это выглядит так. Команда оценивает историю "частичный возврат заказа" в интернет-магазине, разработчик показывает карту 3, а тестировщик 8. Он объясняет, что возврат нужно проверить при оплате картой, бонусами и смешанной оплате, и в каждом случае ещё уведомление покупателю и чек. После обсуждения оценку поднимают, а проверки, о которых вспомнил тестировщик, попадают в критерии приёмки.

В программе 2023 года техники названы прямо: оценка по соотношению, экстраполяция, Wideband Delphi и оценка по трём точкам с той же формулой, что выше. Метод "от времени разработки" близок к оценке по соотношению, а оценка по опыту прошлой итерации похожа на экстраполяцию.

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

• Продукт

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

• Процесс разработки

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

• Люди

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

• Результаты тестирования

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

Видеоурок, шпаргалка и тренажёр

Оценку трудозатрат я разбираю в ролике "Эстимация в тестировании" на YouTube и считаю пример по тест-кейсам и по трём точкам в интеллект-карте. В бесплатном базовом курсе по тестированию тема идёт уроком "Оценка трудозатрат (эстимация) в тестировании", и после теории в нём есть задания. Оценка входит в тест-план, и о нём я рассказываю в следующем уроке.

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

• Урок курсаЭтот урок с заданиями – бесплатно
• Мой видеоурокэстимация в тестировании
• Шпаргалкаоценка трудозатрат в тестировании
• Тренажёроценка трудозатрат по трём точкам
• СтатьяТест-план и тестовая стратегия
• СтатьяЧек-лист и тест-кейс: в чём разница

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441

Вопросы и ответы