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

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

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

(snip)

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

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

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

Are you talking about automated unit/integration tests or manual tests?

For the former, my rule of thumb (based on measurements) is 40-50% added to development time i.e. if developing a use case takes 10 days (before an QA and serious bugfixing happens), writing good tests takes another 4 to 5 days - though this should best happen before and during development, not afterwards.

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

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

When you speak of tests, you could mean waterfall or agile test development. In an agile environment, developers should spend 50% of their time developing and maintaining tests.

But that 50% extra will save you time when the re-factoring and manual verification time comes.

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

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

РЕДАКТИРОВАТЬ: Обратите внимание, что я обычно пишу код сначала с тестом. Если мне придется прийти постфактум и написать тесты для существующего кода, это замедлит работу. Я не считаю, что разработка, ориентированная на тестирование, вообще меня тормозит, за исключением очень исследовательского (читай: одноразового) кодирования.

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

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

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

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