Как оценить время на задачи по тестированию?

Все, что касается управления тестированием ПО...

Модератор: YuriY

Как оценить время на задачи по тестированию?

Сообщение YuriY » 10 фев 2008, 04:38

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

Как оценить время, необходимое для выполнения работ по тестированию? Как учитывать время на многократное выполнение тестирования одного и того же компонента?
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Сообщение despair » 17 мар 2008, 12:43

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

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

Вобще можно выходить на 20-30% времени от девелопмента.
100 часов на кодирование - 20-30 часов на тестирование.

Опять таки повторюсь, это зависит от опыта, чем больше проектов вы оттестировали - тем грамотней эстимейт вы составите.
best regards,
Sergey
despair
Junior
 
Сообщений: 15
Зарегистрирован: 17 мар 2008, 11:41
Откуда: Харьков

Сообщение wishaway » 17 мар 2008, 13:54

Согласен с цифрой 20-30% от девелопмента. У нас тоже так для большинства проектов. Есть исключения, но их не так много.
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Сообщение МандарЫнка » 10 апр 2008, 17:39

ИМХО затраты на тестирование считаются исключительно от требований к тест. результатам.
к примеру, если тестить надо на 3х Оськах то 20% * 3.
если разные браузеры- аналогично.
если надо проводить нагрузочное- еще увеличение на времязатраты
если система более-менее крупненькая прийдется еще тратить время на создание\обновление ТС. тут уже будет много зависить о продробности ТС.

никогда нельзя сказать что 20% это нормально, а 50% много.

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

т.е прежде всего стоит отталкиваться от того, что должно быть выполнено в процессе тестинга
МандарЫнка
Junior
 
Сообщений: 25
Зарегистрирован: 10 апр 2008, 11:49

Сообщение wishaway » 14 апр 2008, 11:20

Аленушка писал(а):никогда нельзя сказать что 20% это нормально, а 50% много.

...

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



А мы тут воду и не мутим, собственно. Мы написали усредненное время для наших проектов. Ясное дело, что для разных проектов и в разных компаниях время будет разное.

Иногда и 100% бывает мало, а иногда и 10% хватает с головой (реальные случаи из моей практики).
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Сообщение Corrigan » 03 июл 2008, 16:45

20-30% на тестинг - это нормальная эмпирическая оценка... она характерна to most projects most of the time... :)

вот только 20-30% не от девелопмента, в том смысле что не от кодирования... это доля тестинга в одном жизненном цикле продукта без учета сопровождения... Кодинг занимает примерно ту же долю - порядка 20%...

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

Обсчитать функциональное тестирование:
1. Выписать ключевые логические модули приложения
2. Провести декомпозицию фич до 2-3 уровня
3. Сопоставить каждой задаче временную оценку в диапазоне 2-8 часов исходя из работы миддл тестера (если так не получается, перепроведите декомпозицию)
4. Просуммировать часы и умножить сумму на 1.3 (набрав опыта умножайте на 1.15)

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

Итого готова оценка тестинга... Все взято с опыта.. Было время когда я по паре проектов в неделю эстимейтил.. :))
лучше зарепортить небаг чем не зарепортить баг!
Corrigan
Newcomer
 
Сообщений: 1
Зарегистрирован: 03 июл 2008, 16:02
Откуда: Харьков

Сообщение OlegY » 02 дек 2009, 16:00

Именно для этого руководитель проекта должен составить STP .
При условии , что у него есть опыт работы и STP составлен правильно , в ганте можно получить очень точную дату окончания проекта и человекоресурсы необходимые для этого.
На мои взгляд базироваться на процентом соотнешении совершенно не приемлимо.
OlegY
Newcomer
 
Сообщений: 4
Зарегистрирован: 02 дек 2009, 14:16
Откуда: Israel


Вернуться в Управление тестированием ПО | Test Management

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5

cron