BDD/TDD против JAD?

Question

Я предлагаю, чтобы мое рабочее место реализовало Behavior-Driven-Development, написав спецификации высокого уровня в формате сценария и таким образом, что можно было бы написать для него тест.

Я знаю, что работа с тестируемыми спецификациями имеет значение increase developer productivity. И я уже думаю о нескольких примерах, где это будет иметь место в нашем собственном проекте.

Однако трудно продемонстрировать ценность этого для бизнеса.

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

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

Это, по их словам, достаточно для разработчиков, и нет необходимости изменять способ написания спецификаций.

Кажется, что у них есть точка.

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

Answer 1

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

Что происходит в вашей ситуации, когда вы думаете, что это улучшится?

Главное преимущество BDD заключается в улучшении связи между заинтересованными сторонами и разработчиками.

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

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

Answer 2

Это может помочь подумать о BDD в его самой легкой форме; как дискуссии вокруг конкретных сценариев.

У вас есть ваши прецеденты. У вас есть свои требования. Теперь вы хотите убедиться, что у вас есть хорошее понимание этих. Так что кто-то - может быть, разработчик, может быть, тестер, - говорит: «Хорошо, просто чтобы убедиться, что я понимаю ... учитывая, что мы начинаем с < >, когда пользователь делает <, это >, тогда < это > должно произойти. правильно?"

И тестер скажет: «Да, это правильно».

Тогда UX или аналитик говорит: «Ну, это правильно, если только < этот другой контекст существует >».

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

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

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

Answer 3

Это отличный вопрос, на самом деле это вопрос «нижней линии», когда речь заходит о BDD. Одна из основных проблем TDD или написания unit-test заключается в том, что разработчикам никогда не кажется, что они имеют большую картину и деловую перспективу. Упражнение написания спецификаций и тестов единиц измерения для проверки реальных «бизнес-сценариев» помогает разработчикам повысить уровень своего «мастерства» и понять перспективы бизнеса. Проверьте этот пост на протяжении более подробной информации,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 4

Я просто наткнулся на этот вопрос, и думал, что я весить потому что это действительно очень интересный вопрос.

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

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

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

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

:-)