Оценка трудозатрат на тестирование

Можно, конечно, "на глазок" оценивать трудозатраты, но, чем дальше в лес, тем толще партизаны. Кто-нибудь использует какие-нибудь методики или формулы для оценки, например затрат на тестирование новой функциональности или регрессионного тестирования?

Что известно на входе?
Количество тестов на версию, количество версий в месяц (год), количество тестовых окружений?

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

Количество тестов. Ну как по мне, то 10 тестов и 1000 тестов всё-таки разница есть.

Умножая на кол-во окружений кол-во тестов получаем количество тестов в одном прогоне - по-моеу составляющие равноценные для оценки трудозатрат по тестированию.

Вот как эти временные затраты (на разработку и тестирование) примерно должны соотностится.

Не факт, абсолютно. На форуме не раз приводились примеры обратного. Из моего опыта: есть модуль, который разрабатывался одним человек в течении 8 часов, для тестирования которого требуется усилия 3-4 тестеров и 5 дней работы.

Зависит от проекта.

Количество тестов. Ну как по мне, то 10 тестов и 1000 тестов всё-таки разница есть.

Умножая на кол-во окружений кол-во тестов получаем количество тестов в одном прогоне - по-моеу составляющие равноценные для оценки трудозатрат по тестированию.

Это примерно понятно.
Давайте упростим задачу. Тестирование ручное, а тесты ещё не разработаны (новая функциональность). Давайте сузим круг и будем говорить только о функциональном тестировании. UI, Performance etc не учитываем. Как быть в таком случае?

Не факт, абсолютно. На форуме не раз приводились примеры обратного. Из моего опыта: есть модуль, который разрабатывался одним человек в течении 8 часов, для тестирования которого требуется усилия 3-4 тестеров и 5 дней работы.

Зависит от проекта.

А этот человек только кодировал модуль 8 часов или ещё было затрачено время, например, руководителя проекта, системного аналитика, ну или ещё кого?

Я не совсем понял упрощённую задачу. По-моему это просто естимирование задач, которые будут делаться? При чём тут зависимост от разработки, планирования?

В моем примере был чистый кодинг.

По-моему это просто естимирование задач, которые будут делаться?

Я не думаю, что все читающие форум хорошо знают албанский :)
Но вообще-то тему я так и назвал "Оценка трудозатрат на тестирование". Может быть, я думал, это как-то зависит от времени разработки, планирования... От чего, получается, тогда надо плясать? И кто как оценивает трудозатраты, если вообще оценивает? Вот это я хотел спросить.

Албанский учить! :) Estimate имелось в виду, вдруг кто-то не уловил.

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

Можно, наверное, на основе собранной по проекту статистики получить какие-то оценки для задач планирование/дизайна/разработки и скоррелировать с реальными трудозатратами на тестирование этих же функциональных модулей, только по-моему слишком притянута будет такая оценка за уши. Как грубый прогноз использовать можно - но погрешность будет высокой.

если вообще оценивает?

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

Нескромный вопрос можно? А как вы работаете сейчас?

Нескромный вопрос можно? А как вы работаете сейчас?

Сам удивляюсь как работаю! :)
На самом деле описывать долго, задайте конкретный вопрос-отвечу

К задаче можно подходить двояко:
- снизу;
- сверху.

Сверху.
Решающую роль играет опыт предыдущих аналогичных проектов. В прошлый раз примерно такую же задачу мы тестировали 5 часов, выполнили 50 тестов, протестировали на 65% от общего списка требований.

Снизу.
На проекте имеем 100 требований. Каждое требование тестируется одиним тестом. Количество прогонов теста - от 4 раз (минимум) до 8 раз (максимум) - зависит от количество наборов тестовых данных. В среднем тест занимает от 2 до 5 минут. Каждый третий тест падает (по предыдущему опыту), значит плюс 5 минут на занесение проблемы в базу дефектов. Все суммируем по минимуму - получаем самый оптимальный вариан. Затем суммируем время наихудшего варианта. Берем среднее.

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

Кратко:
1) Оценивать трудозатраты на тестирование можно исходя из множества метрик, таких как:
* Число функциональных точек
* Цикломатическая сложность кода
* Общее число различных экранных форм и среднее число элементов интерфейса на них
* Экспертная оценка опытного тестера
* И т.д. И т.п.
2) На мой взгляд, для России совершенно не характерно вычисление первых двух метрик. Требований, как обычно, нет, или они в неактуальном состоянии ...
3) Самый простой способ следует из двух метрик: тип софта и трудозатраты программистов. Ответьте на эти два вопроса и получите результат.
Пример: Коробочный бизнес софт, трудозатраты программистов 7 человеко- лет. На тестирование требуется 3-5 человеко лет. Для внутреннего софта трудозатраты на тестирование можно снизить до 0-3 человеко-лет.

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

Кратко:
1)  Оценивать трудозатраты на тестирование можно исходя из множества метрик, таких как:
  * Число функциональных точек
  * Цикломатическая сложность кода
  * Общее число различных экранных форм и среднее число элементов интерфейса на них
  * Экспертная оценка опытного тестера
  * И т.д. И т.п.
2) На мой взгляд, для России совершенно не характерно вычисление первых двух метрик. Требований, как обычно, нет, или они в неактуальном состоянии ...
3) Самый простой способ следует из двух метрик: тип софта и трудозатраты программистов. Ответьте на эти два вопроса и получите результат.
Пример: Коробочный бизнес софт, трудозатраты программистов 7 человеко- лет. На тестирование требуется 3-5 человеко лет. Для внутреннего софта трудозатраты на тестирование можно снизить до 0-3 человеко-лет.

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

Очень интересный вопрос. Жаль, что мало _практических_ ответов, потому что мне периодически приходится оценивать трудозатраты, и обычно именно тогда, когда о предмете тестирования еще ничего не известно.
Я пытаюсь действовать методом "сверху"(с)Green, но часто это неэффективно, потому что функционал может быть проще/сложнее, экспертных тестеров нет. Потом еще идет поправка на профессионализм программиста. Короче - сплошная лирика.
Хотелось бы узнать, есть ли все-таки более формализированные методы оценки на ситуацию, когда тестируется функционал и еще нет даже четкого описания предмета тестирования?

Коллеги, наверное я вас не понимаю - в теме приведено 2 подхода к оценке и 4 метрики , с помощью которых можно оценивать трудозатраты. Чего не хватает?

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

Цитатой на цитату:

* Общее число различных экранных форм и среднее число элементов интерфейса на них
* Экспертная оценка опытного тестера

* Общее число различных экранных форм и среднее число элементов интерфейса на них
* Экспертная оценка опытного тестера

Вячеслав, а если нет ни первого, ни второго?

Коллеги, наверное я вас не понимаю - в теме приведено 2 подхода к оценке и 4 метрики , с помощью которых можно оценивать трудозатраты. Чего не хватает?

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

Натали, опишите ваше приложение или систему?

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

IMHO, вы ищете черную кошку в темной комнате, в которой ее к тому же нет. Если нет даже описания предмета тестирования, то как можно формализовать оценку трудозатрат на него? Нельзя положить крышу на дом, у которого нет даже стен. Вы можете только представить как эта крыша будет выглядеть. В такой ситуации вы можете только "на глазок" определить сколько же потребуется времени на тестирование.

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

Вот вам формализованный подход. В случае тестирования под одной ОС, в одной конфигурации и отсутствия сложной инсталляции берём, например, 25% от общего планового времени проекта. Значит, формула:
Ттест=Тплан*0.25
Далее вводим коэффициент сложности проекта Ксл. Его значения и количество уровней сложности определите сами (от 0 до 0,4 примерно).
Ттест=Ксл*Тплан*0.25
Если тестируем под несколькими ОС: Ксл*Кos*Тплан(Nos-1)*0.25
Если несколько конфигураций: Ксл*Kconf*Тплан(Nconf-1)*0.25
где Kos/conf-коэффициент, определяющий, насколько увеличивается время тестирования каждой следующей ОС/конфигурации. Предположим, что они между собой равны (в принципе, так и есть) и равны (простите за тафталогию), скажем, 0.2. Тогда всё складываем:
Ксл*0.2*Тплан(Nos-1)+Ксл*0.2*Тплан(Nconf-1)=0.2*0.25*Ксл*Тплан(Nos+Nconf-2)=0.05*Ксл*Тплан(Nos+Nconf-2)
получаем:
Ттест=Ксл*Тплан*0.25+0.05*Ксл*Тплан(Nos+Nconf-2)=Ксл*Тплан(0.25+0.05(Nos+Nconf-2))
осталось прибавить время на инсталляцию проекта
Ттест=Ксл*Тплан(0.25+0.05(Nos+Nconf-2))+Тинст

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

IMHO, вы ищете черную кошку в темной комнате, в которой ее к тому же нет. Если нет даже описания предмета тестирования, то как можно формализовать оценку трудозатрат на него? Нельзя положить крышу на дом, у которого нет даже стен. Вы можете только представить как эта крыша будет выглядеть. В такой ситуации вы можете только "на глазок" определить сколько же потребуется времени на тестирование.

Вот змея и проглотила свой хвост... (смотри первый пост)