сроки тестирования. как их оценивать?

Начну с того, что при разработке параллельно пишутся документы для проведения тестирования - тест план, тест кейсы, стратегия тестирования.
В стратегии тестирования есть такая штука как временная оценка.
Речь идет о фунциональном тестировании как наиболее объемном по времени.
Встает вопрос, сколько по времени в процентах от времени разработки должно занимать тестирование?
Как быть с такими ситуациями, когда найденная в процессе тестирования ошибка является фатальной, т.е не позволяет далее проводить тестирование. Проверка других функций становится невозможной.
Вывод - давать дистрибутив обратно на доработку - сроки сдвигаются.
Как в этом случае быть? Делать краткое приемочное тестирование - типа если в определенном наборе тестов найдена ошибка - отправлять обратно на доработку. Но не всегда такое возможно.
Если кто сталкивался - найдутся оценки для различных видов тестирования - сколько по времени их надо проводить?

В стратегии тестирования есть такая штука как временная оценка.

В стратегии????

Речь идет о фунциональном тестировании как наиболее объемном по времени.

Всегда думал что самое объемное это регрессионое тестирование :)

Встает вопрос, сколько по времени в процентах от времени разработки должно занимать тестирование?

от 0% до 300-400% зависит от разрабатываемого ПО

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

Есть такое понятие как риски (читаем например Демарко Управление рисками)
Я обычно при оценке даю временной интервал, например такая-то работа займет от 3-х до 5 дней и всех очень убедительно прошу ориентироваться на максимальную цифру

Делать краткое приемочное тестирование - типа если в определенном наборе тестов найдена ошибка - отправлять обратно на доработку. Но не всегда такое возможно.

Возможно - делайте, не возможно - не делайте

В стратегии тестирования есть такая штука как временная оценка.

В стратегии????

Речь идет о фунциональном тестировании как наиболее объемном по времени.

Всегда думал что самое объемное это регрессионое тестирование :)

Встает вопрос, сколько по времени в процентах от времени разработки должно занимать тестирование?

от 0% до 300-400% зависит от разрабатываемого ПО

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

Есть такое понятие как риски (читаем например Демарко Управление рисками)
Я обычно при оценке даю временной интервал, например такая-то работа займет от 3-х до 5 дней и всех очень убедительно прошу ориентироваться на максимальную цифру

Делать краткое приемочное тестирование - типа если в определенном наборе тестов найдена ошибка - отправлять обратно на доработку. Но не всегда такое возможно.

Возможно - делайте, не возможно - не делайте

А я почему то думал, что первым всегда идет фунциональное.
От нуля до 300%-400% - слишком неопределенный интервал.

А я почему то думал, что первым всегда идет фунциональное.
От нуля до 300%-400% - слишком неопределенный интервал.

Первым да идет обычно функциональное, но вы написали не про первое/второе, а про объемность.

Для того чтобы дать более точную оценку нужно много всего

размер программного продукта, его сложность, квалификацию программистов/тестировщиков ну и т.д.

Проще идти от наличия времени и сказать что вот за те две недели которые вы нам даете мы сделаем то-то и то-то, а дальше хоть земля тресни

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

P.S. от 0 до 400 - определенный интервал :)

В общем случае отталкиваться от времени разработки нельзя.

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

Для каждой оценивайте объем (в человеко-днях, закладывая разумные гэпы). Выделяйте ресурсы и получайте время.

Если нет опыта работы на аналогичных проектах, то план будет далек от реального.

Вообще-то можно написать в Екселе или еще где, "простенький" калькулятор затрат времени на тестирование. Нужно только более менее адекватно (допустим, исходя из бест практис) расставить коэффициенты.
Дело все в том, что у все данные уже есть:
1. Список фич, кол-во Юзкейсов, требования могут нам дать примерную оценку кол-ва тест кейсов.
2. Необходимые виды тестирования нам тоже известны исходя из требований и вашей практики: регрешн, функциональное, нагрузочное и т.д. - Для них делается отдельный расчет времени.
и т.д.

Т.е. если постараться можно вычислить минимальное время на тестирование... А дальше уже эту цифру ровнять с учетом рисков... Список которых, вы кстати тоже должны писать в вашей "стратегии" тестирования или тест плане...

Может получиться, что в идеале у вас будет на тестирование 500 часов, а после прикидки всех рисков может уйти и все 2000... отсюда и предложенныe Oldman 300-400% сверху...

вот...

Я както пролетел на разнице трудоёмкости и длительности. Трудоёмкость теста была около 2 часов, а по длительности выполнения - 5 дней. (Уход аппаратных часов иначе не проверить.)

В общем случае отталкиваться от времени разработки нельзя.

Почему? Как раз если никаких других вариантов нет, то можно попробовать взять 40-60% от разработки. Грубо, но это оценка.

Тестирование - это специфичная деятельность. Она может поглотить любой объем выделенного времени и его окажется недостаточным.

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

Если говорить о более научном подходе, то существуют методики оценки трудозатрат на программирование. Их общая логика сводится к следующему. Делается ревью всей функциональности и она условно делится на 3 (в разных методиках по разному) категории: легкая, средняя и сложная. Каждая категория имеет свой вес в человеко -часах (разные методики различают разные коэффициенты, они могут быть выделены для конкретной технологии, отрасли промышленности и т.п.). Дополнительно применяется поправочный коэффициент для конкретной компании, полученный на основании анализа статистики по большому числу проектов. Потом все перемножается и выводится приблизительная оценка трудозатрат на реализацию каждой функции. Сумма затрат по каждой функции = трудозатраты по проекту.

Некоторые методики включают в себя общий коэффициент затраты на тестирование, некоторые - нет. Введите свой коэффициент и вычисляйте затраты на тестирование.

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

Если уж на то пошло, что лучше выделить 30-40% бюджета проекта на тестирование.
И уже из бюджета и ресурсов получить время.

Но это применимо только к типовым проектам.
Чем меньше знаний о специфике проекта и процессе разработки, тем дальше эта оценка от реальности.

Почему? Как раз если никаких других вариантов нет, то можно попробовать взять 40-60% от разработки. Грубо, но это оценка.

Если уж на то пошло, что лучше выделить 30-40% бюджета проекта на тестирование.
И уже из бюджета и ресурсов получить время.

Для типовых российских проектов - это очень завышенная цифра. Лучше уменьшить до 10-20, но одновременно поднять затраты на аналитику.

Если уж на то пошло, что лучше выделить 30-40% бюджета проекта на тестирование.
И уже из бюджета и ресурсов получить время.

Это мало. Под бюджетом вы понимаете деньги? Лучше к деньгам не привязыватся вовсе, только ко времени. Из-за сильной разницы в стоимости программистов и тестеров.

Но это применимо только к типовым проектам.
Чем меньше знаний о специфике проекта и процессе разработки, тем дальше эта оценка от реальности.

Я всегда люблю послушать что такое "типовой проект" :) Расскажете? Оценка, кстати, не дальше и не ближе от реальности - так как специфика проекта (предметная область, технология разработки и модель управления проектом) накладывается ну в единичных случаях (когда вы реально делаете R&D а не чистый Development), чтобы там не говорили поборники гибкости :)

Если уж на то пошло, что лучше выделить 30-40% бюджета проекта на тестирование.
И уже из бюджета и ресурсов получить время.

Для типовых российских проектов - это очень завышенная цифра. Лучше уменьшить до 10-20, но одновременно поднять затраты на аналитику.

В целом для Продукта - да лучше, только причём тут аналитика к срокам на тестирование и тому как их оценивать? :) Кстати совет "Лучше [затраты на тестирование] уменьшить до 10-20, но одновременно поднять затраты на аналитику." поход на совет "Лучше сделать не зелёный, а круглый" - бюджеты то разные :)

Типовой проект - это пяток студентов, один из которых по недоразумению назван менеджером, трое девелоперами и один тестировщиком :-)

Я специально сделал упор на бюджет, а не трудозатраты, чтобы не было соблазна "экономить".
Зарплаты квалифицированных тестировщиков сопоставимы с девелоперскими.

Если бюджет проект в $100K, а тестируют его 3 студента с сумарной зарплатой в $3K, то освоят они его за 10-15 месяцев.
Утрирую, конечно :-)

[Я всегда люблю послушать что такое "типовой проект" :) Расскажете?

Я часто сталкиваюсь с такой проблемой. Для проведения функционального тестирования достаточно четырех часов и около 2х дней на регрессионное тестирование ( два дня это сделать полный прогон всех кейсов). Но при регрессионном тестировании, успешно завершается только 20% тестов, и начинается долгое и мучительное исправление всех ошибок. Причем некоторые тесты бывают в одной сборке проходят, а в последующих опять ломаются. И сроки бывают затягиваются на несколько месяцев. Вопрос, собственно, такой - как определять сроки тестирования, с учет того что заранее неизвестно сколько раз софт будет отдаваться обратно в разработку.

Тут произошла некая подмена понятий.
Это не тестирование, а стабилизация.

И если описанный случай имеет место, то надо не сроки оценивать, а выявлять причины и фиксить процесс.
Оценки можно дать только на основании печального опыта.
Например, после вненсения изменений в определенный функционал требуется 20 билдов на стабилизацию.
На фиксы и сборку уходит 3 дня, на регрешн 2. Итого 20 недель.
Иногда проект на этой стадии закрывается.

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

Я часто сталкиваюсь с такой проблемой. Для проведения функционального тестирования достаточно четырех часов и около 2х дней на регрессионное тестирование ( два дня это сделать полный прогон всех кейсов). Но при регрессионном тестировании, успешно завершается только 20% тестов, и начинается долгое и мучительное исправление всех ошибок. Причем некоторые тесты бывают в одной сборке проходят, а в последующих опять ломаются. И сроки бывают затягиваются на несколько месяцев. Вопрос, собственно, такой - как определять сроки тестирования, с учет того что заранее неизвестно сколько раз софт будет отдаваться обратно в разработку.

Спасибо за ответ, вы очень правы. Подумать действительно есть над чем.

Немного поздновато, но поделюсь своим опытом.
Для функционального тестирования, если приложение состоит в основном из GUI, то берется по 2 часа на экранную форму на модель и на тестирование. Тупо, считается количество экранных форм. При чем это может быть сложная форма типа трейдинговой операции или платежки, а может быть форма справочника, где код и наименование. Перемножаем количество форм на 4 часа, добавляем еще 30% к полученной сумме и получаем трудоемкость на разработку тестовой модели и на одну итерацию тестирования.
Грубая оценка такая, но позволяет оценить порядок (точность при этом около 90%. 10% - это форс мажоры и неучтенка)

Если более тщательно подходить, то нужно выявить 3 категории сложности форм и посчитать сколько сложных, сколько средних и сколько легких. Для каждой категории прикинуть время на модель и выполнение. перемножить, сложить, получить срок. Добавить 30% и получаем итого.

А вообще-то нужно все тщательно планировать, причем и моменты согласования, и возможные итерации тестирования.

Если нет экранных форм, то можно идти от функций API, или/и от количества таблиц в СУБД. Там также по сложности.
Если сложную бизнеслогику реализовывает приложение (бизнес процессы), то тут считаем по процессам и подпроцессам.

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

Я также присоединюсь к другим авторам и скажу, что в среднем на двух-трех разработчиков хватает одного тестировщика.

А если сложная бизнес-логика? Как обосновать свои трудо- и время- затраты? Есть ли какие-то документы, ГОСТы, которыми можно размахивать перед разработчиками, чтоб бы они больше не говорили, что на тестирование сложнейшей бизнес логики должно уйти пара дней от силы?

А если сложная бизнес-логика? Как обосновать свои трудо- и время- затраты? Есть ли какие-то документы, ГОСТы, которыми можно размахивать перед разработчиками, чтоб бы они больше не говорили, что на тестирование сложнейшей бизнес логики должно уйти пара дней от силы?

Разбиваете на части, прикидываете тесты, оцениваете... А почему вы что-то должны доказывать разработчикам? Это вообще не их ума дело.