# Оценка трудозатрат Например, есть математические проработки: * [Метод оценки по 3 точкам (Three Point Estimation)](https://habr.com/ru/post/248325/); * [Широкополосный метод Дельфи (Wideband Delphi technique)](https://www.tutorialspoint.com/estimation_techniques/estimation_techniques_wideband_delphi.htm); * [Модель издержек разработки (COCOMO - COnstructive COst MOdel)](https://ru.wikipedia.org/wiki/COCOMO) Это математические методы, но я не видел ни одной компании, которая бы использовала их. Да и есть гораздо проще методы. Я считаю, что лучше использовать 2 методики: * Структура декомпозиции работ. * Оценка[, основанная на опыте](https://existek.com/blog/how-calculate-man-hours-software-project-explanation-example/) Берешь свои требования, и большую задачу разбиваешь на множество простейших. Например: тестирование полей, тестирование кнопок, тестирование локализации, тестирование перфоманса и т.д. А дальше дробите по вводам чисел, букв, символов и т.д. ### Алгоритм оценки трудозатрат на тестирование Предлагаю следующий алгоритм для оценки трудозатрат на тестирование ПО: 1. Декомпозиция требований и определение количества тестов 2. Ср. время на разрботку и выполнение 1 теста 3. Определить сколько может быть ошибок и время на 1 дефект 4. Доп. затраты времени и риски. В качестве функционала рассмотрим простую web-форму со строкой ввода, которая позволяет складывать 2 числа: #### 1. Декомпозиция требований и определение количества тестов Как это обычно бывает, не все требования явно прописаны в ТЗ, закладываем на это время + считаем время простейшим тестам. Допустим получили 25 тестов #### 2. Ср. время на разработку и выполнение 1 теста Количество тестов мы получили, теперь нужно определить сколько времени потребуется на то чтобы: а) Описать тест-кейс б) Выполнить проверку по тест-кейсу * Допустим мы знаем, что в каждом тест-кейсе у нас примерно равное количество шагов (в среднем 3-5) а остальные части одинаковые по структуре. Тогда, если на описание 1 тест-кейса уйдет, например, 20 минут, то мы можем умножить это на количество тестов: 20х25=500 мин. * Выполнение проверки по тест-кейсу: оцениваем также т.е. время на выполнение 1 шага (например, 2 минуты), берем среднее количество шагов в тесте (например, 5), итого 10 минут на тест-кейс. Далее умножаем это время на количество тестов, получаем: 10х25=250 минут на 1 полный прогон всех тестов. #### 3. Определить сколько может быть ошибок и время на 1 дефект Тут надо посчитать нам 3 момента: **а) С каким количеством ошибок мы вообще столкнемся** Конечно же количество ошибок может зависеть от кучи факторов: сложность системы, от квалификация команды, от требований… Нам надо понять “на какое количество тестов в среднем будет приходиться одна ошибка?”. Допустим, ошибка будет на каждом 5 тесте или 20% проверок позволят выявить ошибки в тестируемом ПО. В этом случае мы получаем 25/5=5 **б) Сколько времени необходимо на регистрацию ошибки** Время для описания и регистрации 1 дефекта тоже что и оформление 1 тест-кейса. Поэтому на заведение 5 дефектов нам необходимо: 5х20=100 минут **в) Сколько времени уйдет на проверку исправлений** * Не всегда все ошибки исправляются с первого раза, поэтому иногда будут необходимо несколько итераций перепроверки. Чтобы оценить количество ретестов можно либо базироваться на опыте или использовать более или менее стандартную пропорцию: 50% «исправленных» ошибок не проходят перепроверку и их исправляют снова, из них опять 50% не проходят перепроверку и т.д. Получается, что в этом случае мы выполним в 2 раза больше проверок исправления, чем зарегистрировано дефектов. На 1 проверку исправленной ошибки, необходимо столько же времени как и на выполнение тест-кейса. Поэтому для 5 дефектов мы получаем 5х2х20=200 минут на проверки и перепроверки исправленных дефектов. #### 4. Учесть возможные дополнительные затраты времени и риски Оценка этого шага очень сильно зависит от специфики работы\системы\процессов и будет отличаться для каждого частного случая. Поэтому здесь я укажу только варианты направлений и областей, где может теряться дополнительное время: * Подготовка среды тестирования * Взаимодействие с внешними командами * Уточнение требований, вопросы к аналитикам\разработчикам. * Подготовка и установка сборок\билдов * Обновление тест-кейсов Вот так на проработку простейшего функционала может потребоваться целая рабочая неделя! Хотя на первый взгляд и может показаться, что работы там максимум на 1 час. \ Источник: [Алгоритм оценки на тестирование ПО](https://doitsmartly.ru/all-articles/sw-testing/102-test-estimation.html) ### Доп. материал * [Эстимация в тестировании / Оценка трудозатрат на тестирование](https://youtu.be/CfHBhmtES1g)\\ * --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://qabook.gitbook.io/start/teoriya-testirovaniya/processy-v-qa/ocenka-trudozatrat.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.