Поведінково-орієнтована розробка (Behaviour Driven Development

Поведінково-орієнтована розробка (Behaviour Driven Development - BDD), використовується для підвищення цінності, зменшення відходів та покращення комунікації між зацікавленими сторонами та командами постачальників шляхом фокусування на передбачуваній поведінці клієнта для того, щоб рішення задовольняло його потреби.

Дорожня карта продукту (Product Roadmap) одна з методик Agile Extension to the BABOK® Guide v2

Опис Поведінково-орієнтованої розробки (Behaviour Driven Development - BDD) 7.2.2

Agile цінує співпрацю з клієнтами та робочі рішення для досягнення бажаного результату. Фахівці з гнучкого бізнес-аналізу ставлять на перше місце пошук рішень, які поетапно підвищують цінність для клієнта. Поведінково-орієнтована розробка (Behaviour Driven Development - BDD) підтримує цю мету за допомогою використання реальних прикладів.

Поведінково-орієнтована розробка (Behaviour Driven Development - BDD) використовує зрозумілу для користувача мову, специфічну для предметної області, щоб визначити передбачувану поведінку користувача, яка задовольняє його потреби. Це збільшує швидкість доставки, розробляючи тільки те, що потрібно, і створює можливість для автоматизації користувацького тестування.

BDD - це техніка, яка використовується для чіткого визначення потреб і призначена для покращення комунікації та взаєморозуміння між усіма зацікавленими сторонами. Приклади використовуються для того, щоб зрозуміти, що має робити рішення (розробка) і як переконатися, що воно робить те, що потрібно (тестування).

Власник продукту наводить приклади і таким чином пояснює свою думку. Фахівці з гнучкого бізнес-аналізу визначають сценарії, ставлячи питання "що, якщо", щоб виявити додаткові сценарії і висловити їх у вигляді додаткових прикладів.

Обговорення потреб у рішеннях зосереджується на конкретних прикладах, які легко зрозуміти зацікавленим сторонам. Це призводить до більш стабільного набору вимог, ніж використання лише абстрактних моделей. Простий формат, що використовується в BDD, призводить до прямої співпраці між усіма зацікавленими сторонами.

Часто використовуються спільні сесії між власником продукту, тестувальником і розробником. Ці сесії відомі як сесії "Three Amigos". Тісна співпраця спонукає команду розробників думати, як клієнт, і надавати лише те, що необхідно для досягнення бажаної поведінки.

Терміни "Поведінково-орієнтована розробка (Behaviour Driven Development - BDD)", "Приймально-здавальна розробка" (Acceptance Test Driven Development) і "специфікація за прикладом" (Specification by Example) зазвичай використовуються як взаємозамінні.

Елементи Поведінково-орієнтованої розробки (Behaviour Driven Development - BDD) 7.2.3

Приклади Поведінково-орієнтованої розробки

Приклади - це вираження реальних бізнес-сценаріїв, наданих зацікавленими сторонами. Приклади також можуть називатися сценаріями і можуть бути виражені різними способами, включаючи моделі. Фахівці з бізнес-аналізу допомагають виявити інформацію, виражену в прикладах, і гарантують, що набір прикладів є вичерпним.

Приклади використовуються для виявлення інформації про замовника, і не всі знайдені приклади обов'язково будуть входити в сферу розробки.

Синтаксис корнішонів (Gherkin Syntax)

Поведінково-орієнтована розробка використовує простий формат граматики, який називається "корнішон", що дозволяє вставляти в синтаксис реальні сценарії. Це має вигляд:

GIVEN <a situation> / ВРАХОВУЮЧИ <ситуацію>
WHEN <an event> / КОЛИ <подія>
THEN <expected result> / ТОДІ <очікуваний результат>

Як оператори GIVEN (ДАНО), так і кілька результатів THEN (ТОДІ) для одного сценарію можуть бути складними умовами, пов'язаними з операторами AND (І). Існує лише одна подія WHEN (КОЛИ), яка запускає сценарій.

Приклад для банкомату:

Сценарій 1: На рахунку достатньо коштів.

ДАНО (GIVEN): У мене кредит
І (AND): в банкоматі достатньо готівки
КОЛИ (WHEN): Я запитую $20
ТОДІ (THEN): Я отримую $20
І (AND): баланс мого рахунку зменшився на $20

Сценарій 2: На рахунку недостатньо коштів.

ДАНО (GIVEN): У мене перевитрата коштів
І (AND): в банкоматі достатньо готівки
КОЛИ (WHEN): Я запитую $20
ТОДІ (THEN): Я не отримую гроші

Сценарії, написані у форматі Поведінково-орієнтованої розробки, визначають події, умови та дії, які можна перевірити. Вони можуть слугувати критеріями прийнятності історій і тестами на підтримку розробки на основі приймальних тестів, які сприяють загальному розумінню вимог і майбутніх потреб у рішеннях.

Тестування

Існує кілька програмних продуктів, які приймають приклади в цьому форматі (але можуть мати власний специфічний синтаксис і структуру) і дозволяють легко перетворювати їх в автоматизовані тести, що сприяє більш гнучкому виконанню завдань. Автоматизація прикладів покращує і прискорює перевірку та валідацію гнучкого аналізу.

Міркування щодо використання Поведінково-орієнтованої розробки (Behaviour Driven Development - BDD) 7.2.3

Сильні сторони Поведінково-орієнтованої розробки

Поведінково-орієнтована розробка (Behaviour Driven Development - BDD) виражає потреби клієнта природною мовою, у форматі, який легко зрозумілий усім членам команди. Мова базується на конкретних прикладах, а не на абстрактних поняттях.
Шаблон "Дано - Коли - Тоді" безпосередньо відповідає шаблону "Налаштувати - Виконати - Затвердити", який гнучкі розробники використовують у Test Driven Development. Це означає, що розробники можуть безпосередньо реалізовувати тести, а не інтерпретувати їх.
Структура BDD піддається автоматизації приймального тестування і підтримує створення ефективних тестових кейсів.
Існують інструменти для підтримки використання BDD в проектах, які надають додаткові метрики, такі як покриття тестових кейсів або вимоги.
Автоматизовані приклади забезпечують довгострокову документацію системи і можуть бути використані для демонстрації простежуваності вимог для внутрішніх зацікавлених сторін і зовнішніх зацікавлених сторін, таких як регуляторні органи.
Сценарії можна легко розставити за пріоритетами, що підтримує ітеративний, інкрементальний характер гнучких проектів.
Забезпечує гнучкість документації, створюючи легкі, живі вимоги та тестові документи.
Може використовуватися як критерій прийнятності для користувацької історії.
Синтаксис Корнішона можна використовувати для полегшення та структурування проектних обговорень, щоб команда розробників могла зосередитися на конкретній поведінці системи. Це особливо актуально, коли ця техніка використовується у зворотному напрямку на високорівневому дизайні.

Обмеження Поведінково-орієнтованої розробки

Можна пропустити важливі сценарії, якщо немає людини, яка б активно ставила питання "а що, якщо" і "а як щодо".
Якщо бізнес-правила дуже складні, може бути занадто багато сценаріїв, якими важко керувати і відстежувати без підтримки інструментів.
Ті, хто підтримує сценарії та тестові кейси, повинні підтримувати їх актуальними, релевантними та легкими для читання, щоб вони ефективно виконували свою функцію.

Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.