оценка усилий тестирования в процентах от времени разработки [закрыто]
кто-нибудь использует эмпирическое правило для оценки усилий, необходимых для тестирования, в процентах от усилий, необходимых для разработки? И если да, то какой процент вы используете?
10 ответов
когда вы оцениваете тестирование, вам нужно определить объем вашего тестирования - мы говорим о модульном тесте, функциональном, UAT, интерфейсе, безопасности, нагрузке на производительность и объеме?
Если вы находитесь в проекте водопада, у вас, вероятно, есть некоторые накладные задачи, которые довольно постоянны. Дайте время на подготовку любых документов планирования, графиков и отчетов.
для фазы функционального теста (я "системный тестер", так что это моя основная точка отсчета) не забудьте включить планирование! Тестовый случай часто требует по крайней мере столько же усилий, чтобы извлечь из требований / спецификаций / пользовательских историй, сколько потребуется для выполнения. Кроме того, вам нужно включить некоторое время для поднятия / повторного тестирования дефектов. Для более крупной команды вам нужно учитывать управление тестами-планирование, отчетность, встречи.
Обычно мои оценки основаны на сложности предоставляемых функций, а не на проценте усилий разработчиков. Однако для этого требуется доступ, по крайней мере высокоуровневый набор инструкций. Годы тестирования позволяют мне понять, что для подготовки и выполнения теста определенной сложности потребуется x часов усилий. Некоторые тесты могут потребовать дополнительных усилий для настройки данных. Некоторые испытания могут включать переговоры с внешними системами и иметь продолжительность, значительно превышающую требуемые усилия.
в конце концов, вам нужно рассмотреть его в контексте общего проекта. Если ваша оценка значительно выше, чем для BA или Тогда может быть что-то не так с вашими основополагающими предположениями.
Я знаю, что это старая тема, но это то, что я пересматриваю в данный момент и представляет постоянный интерес для менеджеров проектов.
Блог Тестирования Google недавно обсуждали эту проблему:
таким образом, наивный ответ заключается в том, что письменный тест несет налог 10%. Но мы платим налоги, чтобы получить что-то взамен.
(snip)
эти преимущества переводят к реальному значению сегодня так же, как завтра. Я пишу тесты, потому что дополнительные преимущества я получаю более чем компенсировать дополнительные расходы на 10%. Даже если я не включаю долгосрочные преимущества, ценность, которую я получаю от теста сегодня, стоит того. Я быстрее разрабатываю код с помощью test. Сколько, ну это зависит от сложности кода. Чем сложнее то, что вы пытаетесь построить (больше ifs/циклов/зависимостей), тем больше польза от тестов.
по моему опыту, 25% усилий тратится на анализ; 50% - на проектирование, разработку и модульные испытания; оставшиеся 25% - на тестирование. Большинство проектов будет соответствовать + / -10% дисперсии этого эмпирического правила в зависимости от характера проекта, знаний о ресурсах, качестве входов и выходов и т. д. Можно добавить накладные расходы на управление проектами в этих процентах или как накладные расходы сверху в диапазоне 10-15%.
несколько лет назад, в критической области безопасности, я слышал что-то вроде одного дня для модульного тестирования десяти строк кода.
Я также наблюдал 50% усилий для разработки и 50% для тестирования (не только модульное тестирование).
вы говорите об автоматизированных модульных / интеграционных тестах или ручных тестах?
для первого мое эмпирическое правило (основанное на измерениях) на 40-50% добавляется ко времени разработки, т. е. если разработка варианта использования занимает 10 дней (до QA и серьезного исправления ошибок), написание хороших тестов занимает еще от 4 до 5 дней - хотя это лучше всего должно произойти до и во время разработки, а не после.
время тестирования, вероятно, более тесно связано с областью функций, чем время разработки. Я также утверждаю (возможно, спорно), что время тестирования коррелирует с навыками вашей команды разработчиков.
для разработки от 6 до 9 месяцев я требую абсолютного минимума времени тестирования 2 недель, выполняемого фактическими тестировщиками (а не командой разработчиков), которые хорошо разбираются в программном обеспечении, которое они будут тестировать (т. е. 2 недели не включают время наращивания). Это для проект, который имеет ~5 разработчиков.
когда вы говорите о тестах, вы можете иметь в виду водопад или гибкую разработку тестов. В гибкой среде, разработчики должны тратить 50% своего времени на развитие и поддержание тестов.
но что 50% дополнительно будет сохранить вы время когда ре-факторинг и ручное время проверки приходят.
Gartner в октябре 2006 года утверждает, что тестирование обычно занимает от 10% до 35% работы над проектом системной интеграции. Я предполагаю, что это относится к методу водопада. Это довольно широкий диапазон, но существует множество зависимостей от количества настроек стандартного продукта и количества интегрируемых систем.
единственный фактор времени I в дополнительном времени для тестирования - если я не знаком с технологией тестирования, которую я буду использовать (например, используя тесты Селена в первый раз). Затем я учитываю, возможно, 10-20% для ускорения работы инструментов и создания тестовой инфраструктуры.
в противном случае тестирование является просто врожденной частью разработки и не требует дополнительной оценки. На самом деле, я бы, вероятно, увеличил оценку для кода done без тесты.
EDIT: обратите внимание, что я обычно пишу тестовый код. Если я должен прийти после факта и написать тесты для существующего кода, это замедлит процесс. Я не нахожу, что разработка test-first замедляет меня вообще, за исключением очень исследовательского (читай: выброшенного) кодирования.
судите по вчерашней погоде. Сколько времени это заняло в прошлый раз? Вы тренды длиннее или короче? Каждый магазин отличается.
большинств проворным магазинам нужно много меньше времени, иметь drastically меньше дефектов, и более быстрого времени разрешить их из-за TDD. Тем не менее, большинство гибких магазинов имеют некоторое измеримое время, проведенное с тестированием/QC.
Если это первый тестовый запуск для этого приложения, то ответ "давайте посмотрим" последовала попытка. Это зависит от того, как быстро вы можно получить ответы на вопросы, - как проверяемым это, - сколько функций / функций - сколько дефектов обнаружено, - как быстро решаются вопросы, - сколько циклов кода через испытание, и - сколько раз тестирование блокируется жуки. Невозможно сказать. Вы можете назвать это 50% или 175% или более и не ошибаться. Почему не догадываться, и умножить на Пи? Это будет не намного хуже, чем любой другой ответ, который вы можете придумать.
вы должны (должны) знать, сколько времени это занимает сейчас и становится ли это быстрее или медленнее, и увеличивается ли охват или уменьшается. С этими тремя битами информации, вы должны быть в состоянии догадаться довольно хорошо.