Оценка усилий по тестированию в процентах от времени разработки

Ответ 1

Когда вы оцениваете тестирование, вам нужно определить объем вашего тестирования - говорим ли мы unit test, функциональный, UAT, интерфейс, безопасность, производительность и объем?

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

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

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

В конце концов, однако, вам нужно просмотреть его в контексте общего проекта. Если ваша оценка намного выше, чем для BA или Development, то может быть что-то не так с вашими исходными предположениями.

Я знаю, что это старая тема, но это то, что я сейчас пересматриваю и многолетний интерес для менеджеров проектов.

Ответ 2

Блог Google Testing недавно обсуждал эту проблему:

Итак, наивный ответ заключается в том, что письменный тест несет 10% -ный налог. Но мы платим налоги, чтобы получить что-то взамен.

(надрез)

Эти преимущества переходят на реальную ценность как сегодня, так и завтра. Я пишу тесты, потому что дополнительные преимущества я получаю больше, чем компенсировать дополнительную стоимость в 10%. Даже если я не буду включать долгосрочные выгоды, ценность, которую я получаю сегодня от теста, стоит того. Я быстрее разрабатываю код с тестом. Сколько, ну, это зависит от сложности кода. Чем сложнее то, что вы пытаетесь построить, тем больше (плюс ifs/loops/dependencies), тем лучше преимущество тестов.

Ответ 3

По моему опыту, 25% усилий потрачено на анализ; 50% для дизайна, разработки и Unit Test; оставшиеся 25% для тестирования. Большинство проектов будут соответствовать +/- 10% -ному разбросу этого эмпирического правила в зависимости от характера проекта, знаний о ресурсах, качестве входов и выходов и т.д. В этих процентах или в качестве накладные расходы сверху в пределах 10-15%.

Ответ 4

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

Я также наблюдал 50% усилий для разработки и 50% для тестирования (не только модульное тестирование).

Ответ 5

Вы говорите об автоматических тестах на единицу/интеграцию или ручных тестах?

В первом случае мое эмпирическое правило (на основе измерений) добавляется к времени разработки на 40-50%, т.е. если разработка варианта использования занимает 10 дней (до того, как произойдет QA и серьезное исправление ошибок), запись хороших тестов займет еще 4 до 5 дней - хотя это лучше всего делать до и во время разработки, а не потом.

Ответ 6

Когда вы говорите об испытаниях, вы можете сказать о водопаде или гибкой разработке теста. В гибкой среде разработчики должны потратить 50% своего времени на разработку и сопровождение тестов.

Но это 50% дополнительно сэкономит вам время, когда произойдет повторное факторинг и время проверки вручную.

Ответ 7

Gartner в октябре 2006 года заявляет, что тестирование обычно потребляет от 10% до 35% работы над проектом системной интеграции. Я предполагаю, что это относится к методу водопада. Это довольно широкий диапазон, но есть много зависимостей от количества настроек стандартного продукта и количества интегрируемых систем.

Ответ 8

Время тестирования, вероятно, более тесно связано с областью действия, чем время разработки. Я бы также утверждать (возможно, спорное), что время тестирования коррелирует с мастерством команды разработчиков.

Для усилий по разработке от 6 до 9 месяцев я требую абсолютного минимального времени тестирования на две недели, выполняемого фактическими тестировщиками (а не командой разработчиков), которые хорошо разбираются в программном обеспечении, которое они будут тестировать (т.е. 2 недели не включают время разгона). Это для проекта, который имеет ~ 5 разработчиков.

Ответ 9

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

В противном случае тестирование - это всего лишь врожденная часть разработки и не требует дополнительной оценки. Фактически, я бы, вероятно, увеличил оценку кода без тестов.

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

Ответ 10

Судить по вчерашней погоде. Сколько времени прошло в прошлый раз? Вы тянете дольше или короче? Каждый магазин отличается.

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

Если это первый тестовый прогон для этого приложения, тогда ответ "позволяет видеть", за которым следует попытка. Это зависит от того, как быстро вы можете получить ответы на вопросы,  - насколько это возможно,  - сколько функций/функций  - сколько дефектов обнаружено,  - как быстро решаются проблемы,  - сколько раз коды кода  через тестирование и  - сколько раз тестирование блокируется  ошибок. Невозможно сказать. Вы можете назвать это 50% или 175% или более, и не ошибаетесь. Почему бы не сделать приблизительное предположение и умножить на Пи? Это не будет намного хуже, чем любой другой ответ, который вы можете сделать.

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