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

Я немного вокальный сторонник методологии Behavior Driven Development (также известной как BDD). Я применяю BDD уже пару лет, и выбрал StoryQ в качестве своего предпочтительного фреймворка при разработке приложений DotNet. Несмотря на то, что я проходил модульное тестирование в течение многих лет и ранее перешел на подход, основанный на тестировании, я обнаружил, что я получаю гораздо больше пользы от использования инфраструктуры BDD, потому что мои тесты отражают цели требований в относительно ясный английский в моем коде, и потому что мои тесты могут выполнять несколько утверждений, не заканчивая тест на полпути - это означает, что я могу сразу увидеть, какие конкретные утверждения пройдут / не пройдены без отладки, чтобы доказать это.

Это действительно был для меня вершина айсберга, так как я также заметил, что могу отлаживать как тестовый, так и программный код более целенаправленно, в результате чего моя производительность значительно выросла, и я могу больше легко определить, где происходит сбой в случае возникновения проблемы, чтобы пройти весь путь до сборки интеграции из-за выходных данных, попадающих в журналы сборки. Кроме того, API StoryQ имеет прекрасный свободный синтаксис, который легко выучить и который можно применять необычайным количеством способов, не требуя внешних зависимостей для его использования.

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

Таким образом, вопрос действительно сводится к следующему:

1. Какие аргументы я могу использовать, чтобы действительно понять, что для этой команды было бы лучше использовать StoryQ или, по крайней мере, принять методологию BDD?
2. Можете ли вы указать мне какие-либо неподтвержденные доказательства, которые я могу использовать для обоснования своего аргумента о принятии BDD в качестве нашего стандартного метода выбора?
3. Какие контраргументы, о которых вы можете подумать, могут предположить, что мое желание побудить команду принять BDD может быть ошибочным? Да, я счастлив, что оказался неправ, если аргумент является обоснованным.

ПРИМЕЧАНИЕ . Я не защищаю то, что мы полностью переписываем наши тесты, а скорее просто начинаю работать по-другому для всей будущей работы по тестированию, и, предпочтительно, так, как мы привлекаем наших клиентов.

А для тех, кто хочет больше узнать о BDD, могут быть полезны следующие ссылки:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Для тех, кто интересуется более подробной информацией, мы - небольшая команда из 4 человек, которая работает над 5 крупными проектами. «Пилотное испытание» для BDD первоначально длилось около 2 месяцев, а еще через 4 месяца. Команда согласилась, чтобы я продолжал работать таким образом, и должен был провести свои собственные испытания. После окончания судебного процесса я занимаюсь BDD около 2 лет, в то время как другие стали очень хорошо справляться с этой проблемой. Вместо того, чтобы навязывать «конфронтацию» по этому вопросу, я ищу способы мягко убедить команду избавиться от коллективных споров и выделить время, чтобы внести свой вклад.}

Какие аргументы я могу использовать, чтобы действительно понять, что было бы лучше использовать StoryQ или, по крайней мере, применить методологию BDD?

«Клиент хочет этого».

ИМО, вы хотите продавать BDD своим клиентам / экспертам по доменам как минимум столько же, сколько команде разработчиков.

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

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

Дэн Норт рассказывает о том, как вы можете продать BDD бизнесу: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. В группе, не желающей внедрять BDD, скорее всего, нет «аргументов», которые вы могли бы использовать, чтобы «преобразовать» своих коллег в полномасштабное принятие.
    
   Я думаю, что лучшее, что вы можете сделать, - это убедить их попробовать («тест дыма», «пробный прогон», «пилотный проект») - особенно если вы четко даете понять, что отбросите идею, если результаты тестирования отрицательны.
2. Ваш подход к поиску неподтвержденных доказательств идеально вписывается в идею убедить команду попробовать. Для этого я просто поищу в Интернете что-то вроде «Истории успеха разработки, управляемой поведением», и выберу то, что мне легче использовать.
3. Я могу подумать, что есть пара контраргументов, которые могут указывать на то, что ваше желание преобразовать усилия команды в BDD может быть ошибочным.
    
   Ничто из этого не является особенно конструктивным, особенно с точки зрения «защитника изменений», но, к сожалению, вам, вероятно, придется иметь дело именно с такой риторикой ( BTDTGTTS ):
    
   • Вы не можете гарантировать, что общая производительность команды улучшится
   • Вы не можете гарантировать, что усилия, вложенные в принятие BDD, обеспечат значительный возврат инвестиций
   • Команда достаточно хорошо обходилась без BDD, риск изменения нынешнего подхода не оправдан
   • Google (или Microsoft, или IBM - просто введите имя любого «респектабельного» поставщика программного обеспечения) работают без BDD, что «доказывает», что BDD не нужен
   • подходы, не относящиеся к BDD, не получили достаточных шансов в сравнительном тестировании
   • BDD может быть в порядке, но для этого и того модуля / проекта это не применимо

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

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

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

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

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

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