Относительная экономическая эффективность разработки, основанной на тестировании

15

Я хотел бы знать, каково общее влияние планирования ресурсов на программный проект, когда требования и дизайн проекта определяются автоматическими приемочными и модульными тестами, в отличие от более «традиционного» подхода к разработке программного обеспечения.

введите описание изображения здесь

Как, по вашему опыту, в целом влияет на потребности в ресурсах для завершения проекта программного обеспечения в рамках TDD, в отличие от более «традиционных» методологий разработки? Мне кажется само собой разумеющимся, что качество повысится, а количество неопределенности уменьшится, потому что тестирование проводится раньше, но для проведения предварительных испытаний кажется, что для его выполнения потребуется больше часов разработчика. Насколько увеличиваются усилия по разработке или они действительно уменьшаются из-за заблаговременного устранения ошибок?

Сколько еще усилий требуется от клиента? Должны ли они изменить то, как они относятся к проекту, особенно если они привыкли к большому дизайну с самого начала? Увеличивается ли количество часов, необходимое клиенту, или оно действительно уменьшается?

Я полагаю, что оценки времени будут очень расплывчатыми в итеративном процессе TDD в начале проекта TDD (поскольку нет плана разработки программного обеспечения). Есть ли, скажем, 20% в проекте, когда доверие возрастает настолько, что клиенту может быть предоставлена ​​более или менее стабильная оценка времени и денег?

Примечание: я не ищу здесь субъективных мнений или теорий, поэтому, пожалуйста, не спекулируйте. Я ищу больше опыта в TDD.

Роберт Харви
источник
Я уверен, что нет реальных данных. Вы получаете только субъективные мнения и теории, основанные на реальном опыте людей.
Эйфорический
1
@Euphoric: я ищу объективные наблюдения и реалии, основанные на реальном опыте. Извините, я не прояснил это. Однако мне не нужны точные цифры; Я приму общие впечатления, такие как: «хотя время разработки действительно значительно увеличилось, затраты на обслуживание сократились, поскольку программное обеспечение было более надежным, а заказчик понимал его лучше, потому что он принимал участие в разработке на протяжении всего процесса разработки».
Роберт Харви
2
Итак, это вопрос, основанный на мнении? Это, безусловно, звучит как один
BЈовић
@ BЈовић: см. Последний абзац в моем теле вопроса.
Роберт Харви

Ответы:

11

Первое, что нужно сказать, это то, что TDD не обязательно повышает качество программного обеспечения (с точки зрения пользователя). Это не серебряная пуля. Это не панацея. Уменьшение количества ошибок - это не то, почему мы делаем TDD.

TDD делается в первую очередь потому, что он приводит к лучшему коду. В частности, TDD приводит к коду, который легче изменить .

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

Тем не менее, по моему опыту, ценность предложения для TDD растет в геометрической прогрессии, поскольку время и ресурсы, участвующие в проекте, растут линейно.

Хорошие юнит-тесты дают следующие преимущества:

  1. Модульные тесты предупреждают разработчиков о непреднамеренных побочных эффектах.
  2. Модульные тесты позволяют быстро разрабатывать новые функциональные возможности на старых, зрелых системах.
  3. Модульные тесты дают новым разработчикам более быстрое и точное понимание кода.

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

Обобщить:

Разработка на версии 1 может быть медленнее. Разработка на версии 2-10 будет быстрее.

Стивен
источник
1
Мне нравится, когда явное сопоставление «лучшего кода» отличается от повышения «качества программного обеспечения», то есть то, что программисты ценят в коде, не обязательно означает, что он делает то, что хочет клиент.
1
Разве предварительные приемочные испытания и модульные испытания не должны прояснять требования?
Роберт Харви
@RobertHarvey Они должны быть, но не обязательно . Модульные тесты и приемочные тесты будут отражать понимание разработчиком требований при их написании. Разработчики могут иметь что-либо от полного понимания до непонимания требований, когда они начинают писать программное обеспечение. Эта часть уравнения зависит гораздо больше от клиента и менеджера продукта, чем что-либо еще. Теоретически, тесты должны сильно помочь. На практике хорошо, «это зависит».
Стивен
1
Я должен уточнить, мы говорим о TDD в отдельности, а не о реализации SCRUM, которая включает TDD. В отдельности, TDD - это все о написании тестов, так что вы пишете лучший код и можете быстрее и безопаснее проводить рефакторинг.
Стивен
1
@Stephen: Возможно, мне следовало бы прояснить, что я говорю об аромате TDD, который включает в себя приемочные тесты как часть процесса сбора требований. Я добавил графику к вопросу, чтобы сделать это более понятным.
Роберт Харви
6

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

Тематические исследования были проведены с тремя группами разработчиков в Microsoft и одной в IBM, которые приняли TDD. Результаты исследований показывают, что плотность дефектов перед выпуском четырех продуктов снизилась на 40-90% по сравнению с аналогичными проектами, в которых не использовалась практика TDD. Субъективно, после внедрения TDD команды испытали на 15–35% увеличение первоначального времени разработки.

Являются ли эти результаты обобщенными для вашего случая - это, конечно, то, что утверждают сторонники TDD, очевидно, и недоброжелатели TDD будут утверждать, не соответствует действительности.


источник
4
Проблема с этим исследованием в том, что они не тестировали модуль перед адаптацией TDD. TDD не является волшебным инструментом, который уменьшает количество дефектов на 40-90%, просто принимая его
BЈовић
1
@ BЈовић Я не думаю, что они претендуют на «магию» где-то в этой газете. Они утверждают, что некоторые команды приняли TDD, некоторые - нет, им дали «похожую» работу, и были записаны некоторые плотности дефектов и время разработки. Если бы они заставили команды, не использующие TDD, в любом случае писать модульные тесты, чтобы у всех были модульные тесты, это не было бы экологически обоснованным исследованием.
Экологически обоснованное исследование? Сорта зависит от того, что вы измеряете. Если вы хотите знать , является ли писать тесты фронта вопросов, то все должно быть написание юнит - тесты, а не только TDD группы.
Роберт Харви
1
@ Роберт Харви, это вопрос смешанных переменных, а не экологической достоверности. Разработка хорошего эксперимента предполагает градиент. Например, если бы контрольная группа писала юнит-тесты в произвольном порядке, люди могли бы утверждать, что эксперимент был несостоятельным, потому что контрольная группа работала так, как это редко бывает в дикой природе.
2
К счастью, я не сказал, что они были.
5

У меня нет каких-либо исследовательских работ или статистических данных, которые можно было бы вам дать, но я поделюсь своим опытом работы в команде / организации, в которой исторически проводилось единичное тестирование с низким и средним уровнем охвата и отсутствовали сквозные тесты, и постепенно переместить планку туда, где мы сейчас находимся, с большим количеством подхода ATDD (но, как ни странно, не традиционного TDD).

В частности, это то, как сроки проекта использовались (и все еще действуют в других командах / продуктах в той же организации):

  • До 4 недель анализа и внедрения
  • 2 недели регрессионного тестирования, исправления ошибок, стабилизации и подготовки к выпуску
  • 1-2 недели исправления известных дефектов
  • 2-3 недели очистки кода и проблем / поддержки после производства (неизвестные дефекты / незапланированные простои)

Это выглядит как нелепые накладные расходы, но на самом деле это очень часто, во многих организациях это просто маскируется отсутствием или неэффективным контролем качества. У нас есть хорошие тестировщики и культура интенсивного тестирования, поэтому эти проблемы обнаруживаются на ранних этапах и решаются заранее (большую часть времени), вместо того, чтобы им было позволено играть медленно в течение многих месяцев / лет. Затраты на обслуживание на 55-65% ниже, чем общепринятая норма 80% времени, затрачиваемого на отладку, что кажется разумным, потому что у нас было несколько юнит-тестов и межфункциональных команд (включая QA).

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

Напротив, каждый выпуск, начиная с этого первоначального выпуска, имел критерии раннего принятия и приемочные тесты, и наши текущие итерации выглядят так:

  • 8 дней анализа и внедрения
  • 2 дня стабилизации
  • 0-2 комбинированных дня постпроизводственной поддержки и очистки

Другими словами, мы выросли с 55-65% затрат на обслуживание до 20-30% затрат на обслуживание. Та же команда, тот же продукт, главное отличие - прогрессивное улучшение и оптимизация наших приемочных испытаний.

Стоимость их обслуживания составляет в среднем 3-5 дней для аналитика QA и 1-2 дня для разработчика. Наша команда состоит из 4 разработчиков и 2 аналитиков QA, поэтому (не считая UX, управления проектами и т. Д.) Это максимум 7 человеко-дней из 60, что я бы округлил до 15% накладных расходов на внедрение, просто чтобы быть на безопасная сторона.

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

Вы могли заметить, что вторая временная шкала намного более точна и также намного короче первой. Это то, что стало возможным благодаря предварительным критериям приемки и приемочным испытаниям, потому что это значительно упрощает «определение выполненного» и позволяет нам быть гораздо более уверенными в стабильности выпуска. Ни одна другая команда (пока) не преуспела с двухнедельным графиком выпуска, за исключением, возможно, при выполнении довольно тривиальных выпусков обслуживания (только для исправления ошибок и т. Д.).

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

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

Поможет ли вам ATDD в более долгосрочных проектах, выполненных в RUP или (тьфу) стиле «Водопад», проектах продолжительностью 3 месяца или более? Я думаю, что жюри все еще на этом. По моему опыту, самые большие и уродливые риски в долгосрочных проектах - это нереальные сроки и меняющиеся требования. Нереальные сроки приведут к тому, что люди будут использовать ярлыки, в том числе ярлыки для тестирования, а значительные изменения в требованиях, вероятно, сделают недействительным большое количество тестов, что потребует их переписывания и может привести к дополнительным затратам на реализацию.

Я почти уверен, что ATDD имеет фантастическую выгоду для Agile моделей или для команд, которые не являются официально Agile, но имеют очень частые графики выпуска. Я никогда не пробовал это на долгосрочном проекте, в основном потому, что я никогда не был в организации и даже не слышал об организации, готовой попробовать ее в таком проекте, поэтому вставьте здесь стандартный отказ от ответственности. YMMV и все такое.

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

Aaronaught
источник
Это очень полезно, спасибо. Мне не приходило в голову, что ATTD может изменить характер работы TDD, но это имеет смысл, особенно когда вы слышите о людях, которые способны выпустить хорошо написанное, относительно безошибочное программное обеспечение вовремя и в рамках бюджета без обязательно используя модульное тестирование широко.
Роберт Харви
@RobertHarvey: я должен уточнить - мы все еще создаем модульные тесты, но не как часть процесса TDD. Обычно приемочные тесты выполняются сначала или параллельно с первоначальной разработкой, затем завершением кода, затем модульными тестами и рефакторингом. Я иногда думал, что TDD поможет определенным разработчикам написать лучший код, но я не могу подтвердить это (пока). Хотя я могу говорить сам за себя - я часто улавливаю множество ошибок и недостатков дизайна в своем собственном коде просто во время написания модульных тестов.
Аарона
1

Требования к ресурсам

Как, по вашему опыту, в целом влияет на потребности в ресурсах для завершения проекта программного обеспечения в рамках TDD, в отличие от более «традиционных» методологий разработки?

По моему опыту, стоимость обязательных предварительных тестов немедленно снижается путем определения четких критериев приемлемости заранее и последующей записи в тест. Мало того, что стоимость предварительного тестирования снижается, я также обнаружил, что в целом это ускоряет общую разработку. Хотя эти улучшения скорости могут быть уничтожены из-за плохого определения проекта или изменения требований. Тем не менее, мы все еще можем достаточно хорошо реагировать на такого рода изменения без серьезных последствий. ATDD также значительно сокращает усилия разработчика по проверке правильного поведения системы с помощью автоматизированного набора тестов в следующих случаях:

  • большие рефакторы
  • обновления платформы / пакета
  • миграция платформы
  • обновления цепочки инструментов

Это предполагает команду, которая знакома с процессами и практиками.

Участие клиентов

Сколько еще усилий требуется от клиента?

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

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

Оценка проекта

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

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

Например:

«Спринты» моей команды длились неделю, и у нас есть промежуточное среднее и стандартное. отклонение последних 14 недель. Если у проекта 120 баллов, мы имеем среднее значение 25 и стандартное значение. Отклонение от 6, тогда оценка завершения проекта составляет:

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

Мы используем 2 ст. Эмпирическое правило отклонения для нашей оценки достоверности 95%. На практике мы обычно завершаем проект по первому стандарту. отклонение, но над нашим средним. Обычно это связано с доработками, изменениями и т. Д.

dietbuddha
источник
Итак, в основном вы говорите, что TDD улучшает усилия по разработке, побуждая заинтересованные стороны делать те вещи, которые они должны делать в любом случае, такие как обеспечение четких, действенных требований и критериев приемлемости.
Роберт Харви
1
Ну, не только это. По мере развития проекта более активное участие позволяет лучше общаться между разработчиком и заинтересованными сторонами. Это позволяет таким вещам, как dev, предлагать менее дорогие альтернативы, так как их понимание того, что хочет заинтересованная сторона, дорабатывается дальше. Это позволяет заинтересованным сторонам изменять требования раньше, поскольку они понимают, что чего-то не хватает или не будут работать без такого антагонистического ответа от dev; и без многих необоснованных ожиданий, которые обычно исходят от заинтересованных сторон.
диетическая будда
-1

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

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

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

Сколько еще усилий требуется от клиента? Должны ли они изменить то, как они относятся к проекту, особенно если они привыкли к большому дизайну с самого начала? Увеличивается ли количество часов, необходимое клиенту, или оно действительно уменьшается?

Это не должно иметь значения. Тот, кто выполняет требования, должен делать это как можно лучше.

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

Поэтому, если им нравится делать BDUF, пусть делают это. Это сделает вашу жизнь проще как разработчик.

BЈовић
источник
1
Насколько я понимаю, TDD и BDUF вообще не совместимы друг с другом.
Роберт Харви
3
BDUF, как правило, не совместимы с какими-либо хорошими практиками управления развитием. Но было бы возможно сделать проект BDUF в стиле TDD. TDD - это метод создания программного обеспечения лучшего качества, а BDUF - метод выявления требований. Плохая техника, но, тем не менее, техника.
Стивен
@RobertHarvey Правильно, но если они хотят сделать BDUF - это их выбор. Если вы действительно делаете гибкие, то вы можете улучшить их дизайн, и все равно делать TDD.
BЈовић
так что вы говорите, что если я напишу модульный тест, мой код будет полностью протестирован, и если все тесты пройдут, это, конечно, означает, что в программном обеспечении нет ошибок (или, по крайней мере, лучше). Поэтому мне просто нужно протестировать каждый метод моего программного обеспечения, например, "function testSqr () {int a = 3; assertTrue (mySqr (a) == 9);} function mySqr (int a) {return 9;}"
Дайнюс,
@ Дайнюс Нет, перечитайте еще раз. 100% покрытие кода не без ошибок. Да, вам нужно протестировать каждый метод. Конечно, модульное тестирование доступа к базе данных, GUI и т. Д. Не имеет смысла. Модульные тесты не для тех.
BЈовић