Перейти к содержимому

Chrome DevTools: Инструменты тестировщика
онлайн, начало 27 февраля
Английский для тестировщиков
онлайн, начало 2 марта
Selenium IDE 3: стартовый уровень
онлайн, начало 21 февраля
Git: инструменты тестировщика
онлайн, начало 27 февраля
Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 22

#1 Zenturio

Zenturio

    Опытный участник

  • Members
  • PipPipPipPip
  • 386 сообщений
  • ФИО:Дмитрий
  • Город:Смоленск - Москва


Отправлено 14 Август 2008 - 11:18

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

#2 Oldman

Oldman

    Опытный участник

  • Members
  • PipPipPipPip
  • 331 сообщений
  • ФИО:Александр

Отправлено 14 Август 2008 - 11:53

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

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

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

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

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

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

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

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

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

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

#3 Zenturio

Zenturio

    Опытный участник

  • Members
  • PipPipPipPip
  • 386 сообщений
  • ФИО:Дмитрий
  • Город:Смоленск - Москва


Отправлено 14 Август 2008 - 13:14

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

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

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

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

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

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

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

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

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

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


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

#4 Oldman

Oldman

    Опытный участник

  • Members
  • PipPipPipPip
  • 331 сообщений
  • ФИО:Александр

Отправлено 14 Август 2008 - 13:28

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

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

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

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

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

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

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

#5 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 14 Август 2008 - 15:27

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

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

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

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

#6 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 14 Август 2008 - 16:39

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

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

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

вот...
  • 0
Алексей Булат
Про Тестинг

#7 saezar

saezar

    Активный участник

  • Members
  • PipPip
  • 113 сообщений
  • ФИО:Сергей

Отправлено 14 Август 2008 - 17:45

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

#8 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 14 Август 2008 - 18:19

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

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

#9 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 15 Август 2008 - 06:47

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

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

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

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

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

#10 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 15 Август 2008 - 07:49

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

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

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


  • 0

#11 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 257 сообщений
  • Город:Москва


Отправлено 15 Август 2008 - 08:15

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

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

-- 

Сергей Мартыненко

Блог 255 ступеней

 


#12 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 15 Август 2008 - 10:59

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

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

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

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

#13 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 15 Август 2008 - 11:03

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

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



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

#14 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 15 Август 2008 - 14:45

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

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

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

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


  • 0

#15 mnatikk

mnatikk

    Новый участник

  • Members
  • Pip
  • 19 сообщений
  • ФИО:Наталья Мельникова
  • Город:Новосиб

Отправлено 26 Сентябрь 2008 - 11:00

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

#16 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 26 Сентябрь 2008 - 18:37

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

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

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

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


  • 0

#17 mnatikk

mnatikk

    Новый участник

  • Members
  • Pip
  • 19 сообщений
  • ФИО:Наталья Мельникова
  • Город:Новосиб

Отправлено 30 Сентябрь 2008 - 06:14

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

#18 nsimonov

nsimonov

    Новый участник

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Симонов Николай
  • Город:Московская область

Отправлено 24 Ноябрь 2008 - 13:20

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

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

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

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

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

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

#19 julia.ap

julia.ap

    Новый участник

  • Members
  • Pip
  • 23 сообщений

Отправлено 18 Февраль 2009 - 16:06

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

#20 Clauster

Clauster

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 18 Февраль 2009 - 20:49

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

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


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале