Сообщений в теме: 10

[Boltick]

Добрый день.

Возможно эта тема и поднималась, но я ее попросту не нашел.

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

Пример простой: есть ТЗ с требованиями и ЮЗ кейсами, и мне надо сказать сколько времени может занять тестирование.


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

В любом случае буду рад услышать ответ, а также подискутировать на данную тему.

Спасибо

[Clauster]

ага, я поднимал тут подобную тему. Плохо искали http://forums.softwa...hl=трудозатраты

[Boltick]

Да, спасибо... Тему я прочитал...

Но мой вопрос остался не отвеченным. Я спрашивал про стандартные инструменты и методики... И есть ли они вообще :)

Спасибо

[van]

Стандартных нет.

[Clauster]

А что значит стандартные? RUP, MSF, различные agile-методологии и т.д., везде по-своему.

[Alfa]

Как-то в умной книге (не помню какой) читал, что нулевая оценка на время тестирования - это время потраченное на разработку. Ну и дальше идет первый порядок, тут надо думать.
Плюс все сильно зависит от того какого качества продукт хотите получить.

[Yury]

Пример простой: есть ТЗ с требованиями и ЮЗ кейсами, и мне надо сказать сколько времени может занять тестирование.

А что Вы, собственно говоря, хотите рассчитать?
Сколько вам нужно тестеров на данный проект, или за сколько времени имеющиеся тестеры смогут его протестировать?

Обычно работает армейская методика: "Тестирование проводится от забора и до обеда."

[Roman Klochkov]

Не назвал бы это простым примером. То есть пример ничего, только вопрос поставлен не очень корректно.

1. Если интересует "сколько времени может занять тестирование проекта", то ответ один - сколь угодно много (т.е. что у заказчика продукта кончится раньше - терпение или деньги). Продуктов без багов не бывает, бывают терпимые (низко-приоритетные). Не знаю у кого как, мы давно смирились и честно пишем для 90% типов тестов в разделе "критерий окончания тестирования" - завершение тестирования проекта. Просто чем ближе срок релиза, тем больше багов закрываются с комментарием "by design". Хотя в тестировании ПО может всё по другому, не в курсе :)
2. Ну а если интересует "сколько времени займёт один прогон всех имеющихся тестов" - тогда конечно можно получить конкретную цифру.

Хотя мне почему-то кажется что вы спрашивали о первом варианте :)

[Boltick]

Не назвал бы это простым примером. То есть пример ничего, только вопрос поставлен не очень корректно.

1. Если интересует "сколько времени может занять тестирование проекта", то ответ один - сколь угодно много (т.е. что у заказчика продукта кончится раньше - терпение или деньги). Продуктов без багов не бывает, бывают терпимые (низко-приоритетные). Не знаю у кого как, мы давно смирились и честно пишем для 90% типов тестов в разделе "критерий окончания тестирования" - завершение тестирования проекта. Просто чем ближе срок релиза, тем больше багов закрываются с комментарием "by design". Хотя в тестировании ПО может всё по другому, не в курсе :)
2. Ну а если интересует "сколько времени займёт один прогон всех имеющихся тестов" - тогда конечно можно получить конкретную цифру.

Хотя мне почему-то кажется что вы спрашивали о первом варианте :)

Как раз таки меня нитересует пункт [2] а именно: расчет времени в человекочасах :)

Если это все достаточно субъективная оценка, которая делается за счет личного опыта, опыта тестировщиков, а также интуитивно, то тогда у меня вопросов нет. А если есть какие-нить секретные формулы, то мне это очень даже интересно :)

Спасибо

[Green]

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

1. Декомпозировать систему (разбить функц. требования на логические блоки)
2. Оценить количество тестов по каждой компоненте (блоку)
3. Для каждого теста определеить два параметра:
- время прохождения теста без выявления дефекта
- время прохождения теста с выявлением дефекта

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

Далее начинаем обратный путь.

1. Находим среднее время (я встречал рекомендации - 2/3) для каждого теста (успешного и неуспещного варианта)
2. Суммируем все полученные результаты (средние для каждого теста)

Получаем предположительное время тестирование системы при условии соотношения багов к тестам - 1/2 (т.е. баг обнаруживается в каждом втором тесте).

Собирая статистика по соотношению кол-во найденных дефектов к кол-ву выполненных тестов, вы сможете уточнить временные затраты на тестирование в заданном объеме (т.е. количество тестов заранее известно).

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

[SALar]

Посмотрите инструменты по COCOMO-II. Хотя,... Это по научному. А как Сергей описал - будет поточнее.