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

Behavior-driven development, BDD, с английского языка переводится как «Поведенчески–ориентированная разработка». Это понятие относится к гибкой методологии управления Agile. Подход нацелен на то, чтобы стереть коммуникационные преграды между бизнесом и командой разработки, чтобы у них было общее понимание к требованиям по продукту.

Метод BDD исходит из разработки через тестирование (Test Driven Development, TDD), то есть когда тесты готовы раньше написанного кода. Также истоком является подход предметно–ориентированной разработки (Domain Driven Design, DDD), который занимается изучением предметных областей или отдельно взятых бизнес–процессов.

Сам метод разработки Behavior-driven development основывается на трех принципах:

Сотрудничество.

Поведенчески–ориентированная разработка подразумевает, что все участники процесса должны постоянно взаимодействовать между собой. Это позволяет обмениваться актуальной информацией, выстраивать доверительные и уважительные отношения. Кроме того, постоянная коммуникация снижает риск возникновения ошибок в разработке и позволяет своевременно внести изменения в проект.

Общий язык коммуникации.

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

Разработка через тестирование.

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

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

• Обсуждение.

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

• Определение.

На основе полученных данных пишутся BDD–сценарии с использованием общего, доступного всем языка. Для этого может быть использован метод Given-When-Then, который бывает как ручной, так и автоматизированный с помощью специальных инструментов BDD–подхода. Сценарий дает гарантию, что и заказчик, и разработчики поняли суть и цели проекта верно, а значит, в итоге они получат продукт с ожидаемыми результатами.

• Разработка.

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

• Тестирование.

После этого осуществляется запуск автотестов. За основу берутся BDD–сценарии, которые были написаны ранее. Так команда проверяет соответствие кода указанным требованиям.

• Рефакторинг.

Улучшение и упрощение кода для повышения качества продукта и достижения установленной ранее цели, которая была оглашена на этапе обсуждения.

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

Какой именно вклад в разработку программного обеспечения сделал BDD, расскажем ниже:

Улучшение сотрудничества и коммуникации.

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

Улучшение коммуникации за счет общего языка.

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

Рост качества программного обеспечения.

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

Ускорение доставки.

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

Особенно хочется остановиться на коммуникации на общем языке, так как это является отличительной чертой и одним из ключевых принципов Behavior-driven development.

Общий язык.

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

Наглядные примеры.

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

Обратная связь.

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

Живая документация.

Это не просто текст, на который опирается команда разработчиков и тестировщиков, а рабочий документ. Он развивается и масштабируется вместе с проектом.

Ценность для пользователя.

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

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

Применение метода Given-When-Then.

Данный подход позволяет создать четкую структуру сценария.

• Given – дает контекст, то есть какие условия были созданы до начала тестирования.

• When – показывает, какие именно действия совершил пользователь в процессе теста.

• Then – указывает на результат, который был получен во время проверки программного продукта.

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

Точность и емкость.

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

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

Сосредоточенность на пользовательском поведении и реалистичность.

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

Отсутствие деталей реализации.

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

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

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

Ниже рассмотрим некоторые из них:

Cucumber.

Специализированный инструмент Behavior-driven development, имеющий открытый исходный код. Использует язык Gherkin, чтобы перевести BDD–сценарии в формат текстовых спецификаций. Тем самым реализуется гарантия того, что все проверки будут всегда синхронизироваться с указанными требованиями. Кроме того, Cucumber поддерживает множество языков программирования, например, таких как Ruby или Java.

SpecFlow.

Фреймворк для.NET, позволяющий улучшить автотесты на C#. Также использует язык Gherkin для определения BDD–сценариев. Имеет совместимость с NUnit, xUnit и MSTest. Обладает возможностью масштабизации в соответствии с запросами команды по текущему проекту.

Behave.

Ещё один инструмент, использующий Gherkin для определения BDD–сценариев. Его используют для работы с Python. Использует библиотеки шагов, что позволяет Behave быть гибким. Кроме того, он способствует декомпозиции системы на внутренние модули. В связке с Pytest дает возможность осуществлять поддержку согласованности всех проводимых тестов.

JBehave.

BDD–инструмент на основе Java, который с помощью все того же Gherkin позволяет писать человекочитаемые сценарии. Имеет поддержку широкого спектра вариантов выполнения тестов за счет возможности интеграции с другими инструментами тестирования Java.

При выборе инструмента важно обратить внимание на следующие факторы:

• Простой и доступный интерфейс с понятным функционалом и набором инструментов, которым несложно управлять.

• Совместимость с популярными языками программирования, которые команда использует во время разработки.

• Возможность интеграции с другими инструментами тестирования и разработки.

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

Кроме специфических инструментов Behavior-driven development, можно использовать вспомогательные, например, такие как no-code платформа AppMaster.io. Она обладает разнообразными и мощными инструментами визуализации, необходимыми для ускорения разработки приложений.

Интеграция Behavior-driven development в работу компании предоставит ей возможность разрабатывать качественные продукты, которые будут востребованы среди пользователей.

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

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

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

И это лишь некоторые из преимуществ, которые получает команда при применении поведенчески–ориентированного подхода к разработке. Чтобы внедрить метод BDD, требуется пройти несколько шагов. Среди них такие, как:

Согласование принципов работы BDD с командой.

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

Установление рабочего процесса по принципам BDD.

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

Создание единого языка, понятного для всех.

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

Написание BDD–сценариев.

Используя метод Given-When-Then, необходимо написать краткие и понятные сценарии поведения пользователей и программы. Они должны быть реалистичными, без каких–либо гипотез. Чем достовернее он будет, тем корректнее и качественнее будет работа продукта разработки.

Подбор подходящих инструментов для разработки и тестирования.

Исходя из возможностей компании и квалификации команды, нужно подобрать подходящие BDD–инструменты разработки и тестирования. Кроме того, нужно учитывать совместимость с языками и возможность интеграции с другими нужными программами, сервисами и фреймворками.

Автоматизация тестов и рефакторинг.

Для удовлетворения ожидаемого поведения стоит выполнять автотесты на базе BDD–сценариев. По мере необходимости нужно вносить изменения в код, чтобы улучшить полученные ранее результаты. Чем чище и проще он будет, тем лучше.

Внедрение непрерывной интеграции.

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

Переосмысление и интеграции.

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