Поведенческий подход к разработке — это конкретный метод, а не концепция. Behavioral Driven Development (BDD) — вариация Agile-подхода, гибкое управление проектами, основа которого — постоянное развитие продукта и его совершенствование, разбитое на отдельные этапы. 

«В большинстве компаний один из основных KPI — скорость выпуска бизнес-ценностей (удовлетворения потребностей клиента). BDD — гибкий и функциональный инструмент, который может повысить эту скорость», — отмечает Климент Кузьмин, основатель Products School. 

Behavioral Driven Development даёт удобный инструмент для развития. Модель позволяет руководству компании, маркетологам и бизнес-аналитикам активно участвовать в проработке и тестировании новых функций и сценариев работы. Это существенно ускоряет разработку. 

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

Как работает BDD?

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

«BDD позволяет установить потребность бизнеса в разработанной фиче и донести её до всех участников процесса. Одновременно задаются условия, в которых реализуется эта бизнес-ценность, — говорит Климент Кузьмин. — Например, мы реализуем внутри личного кабинета персональные предложения. Для этого производим анализ истории покупок и подсвечиваем то, что клиент уже покупал и на что есть скидка. Чтобы реализовать эту фичу, одной из базовых системных проверок должны стать авторизация пользователей и их истории покупок. Это обязательное окружение, которое нужно фиче для реализации. В BDD мы описываем бизнес-ценность — персональные предложения. А также окружение и исходные условия, в которых она реализуется. Его описание необходимо для постановки максимально точной задачи программистам и тестировщикам. Только в том случае, если каждый понимает суть предложения, его получится реализовать и принять оперативно. Разработчики знают, что им делать, тестировщики понимают, что фича работает только тогда, когда пользователь авторизован и у него есть история покупок. Представители бизнес-части компании получают нужный результат и принимают фичу».

Структура поведенческого подхода к разработке

Основа BDD — модель Given/When/Then. Given — условия, существовавшие до воздействия пользователя на интерфейс. When — действие пользователя (клик по элементам управления, транзакция, поиск по странице). Then — реакция на действие пользователя.

Пример:

Given

— пользователь на стартовом экране интерфейса.

When

— пользователь нажимает кнопку «Посмотреть счёт».

Then

— открывается окно состояния счёта.

Доступны и решения на русском языке. Тогда шаблон трансформируется в «если/когда/тогда», но работает по той же логике.

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

Преимущества и ограничения подхода

Главный плюс BDD — простой язык, который обеспечивает прямой доступ к разработке непрограммистской части компании. C behavioral framework с продуктом напрямую работают те, кто взаимодействует с пользовательским опытом — от маркетологов до собственника компании.

Другое достоинство BDD — постоянное тестирование при разработке. Причём это происходит в формате автоматической проверки по заданному сценарию, что ускоряет и упрощает введение новых функций.

Преимущества Behavioral Driven Development позволяют эффективно использовать его для решения нескольких задач:

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

уменьшения затрат времени и ресурсов на написание документации, так как языком BDD могут пользоваться непрограммисты;

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

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

«Всё зависит от компании и команды, внедряющих  BDD. Важно избежать ситуации, когда тестировщики внедряют модель, а бизнесу нужно решать другие вопросы и вместо ускорения бизнес-ценностей, создания конвейера произойдёт замедление. Бизнес не будет принимать фичи, потому что какие-то требования не были учтены или были услышаны разработчиками неправильно. BDD и последнюю проблему решает — в рамках модели все слышат одно и то же», — говорит Климент Кузьмин. 

А вот другие ограничения сопровождают BDD всегда.

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

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

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

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

Кому выгоден BDD? 

«Компании, которые считают деньги на разработку, используют BDD, востребованность модели возрастает», — отмечает Климент Кузьмин, основатель Products School.

BDD будет полезен в финтехе, эдтехе, здравоохранении и других областях, где во главе угла — пользователь. А также в любых приложениях, где нужно создавать продукт, опираясь на действия клиентов, реальные или предполагаемые. 

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

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

Телеграм-канале

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

Дзен

.