У меня нет каких-либо исследовательских работ или статистических данных, которые можно было бы вам дать, но я поделюсь своим опытом работы в команде / организации, в которой исторически проводилось единичное тестирование с низким и средним уровнем охвата и отсутствовали сквозные тесты, и постепенно переместить планку туда, где мы сейчас находимся, с большим количеством подхода 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 без кого-либо, кто мог бы выполнять эту роль.
