bdd-playbook

Guide BDD scenario writing with business glossary terms and service mappings.

Updated Dec 4, 2025

Search Tags:#glossary #training #scenarios #bdd #observable-outcomes #behavior-driven-development #service-mapping

Ready to run

npx skills add https://github.com/mikivujkovic/claude-code-ddd-tdd-bdd --skill bdd-playbook

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: bdd-playbook
Source: https://github.com/mikivujkovic/claude-code-ddd-tdd-bdd/tree/main/.claude/skills/bdd-playbook
Command: npx skills add https://github.com/mikivujkovic/claude-code-ddd-tdd-bdd --skill bdd-playbook

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you write Behavior-Driven Development (BDD) scenarios in business language, ensuring outcomes are observable and mapping steps to services rather than UI details.

Core Features & Use Cases

Readable scenarios: Use the glossary to keep language consistent.
Observable outcomes: Define measurable results, not UI interactions.
Service mapping: Tie steps to application services rather than screen actions.

Quick Start

Describe a customer signup scenario in business terms, define observable outcomes (e.g., account created, email sent), and map each step to a backend service.

Frequently Asked Questions about bdd-playbook

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I write BDD scenarios that focus on observable outcomes instead of UI steps?▼

Observable outcomes in BDD are measurable results—like 'account created' or 'email sent'—rather than UI interactions. Map each scenario step to backend services and business glossary terms to ensure outcomes are verifiable and tied to application behavior, not screen actions.

What's the difference between BDD scenarios and traditional test cases?▼

BDD scenarios use business language to describe behavior and outcomes, aligning with a shared glossary. Traditional test cases often focus on UI steps. BDD bridges business intent and technical implementation by mapping scenario steps directly to services, making outcomes observable and testable.

How do I map BDD scenario steps to application services?▼

Service mapping translates each scenario step into the backend service it exercises. Instead of 'click signup button,' describe the intent and observable outcome, then identify which service handles that behavior. This keeps scenarios implementation-agnostic and tied to measurable business results.

Can I use BDD for QA workflows without UI automation?▼

Yes. BDD scenarios work well for QA by defining observable outcomes—data changes, API responses, state transitions—rather than UI verification. Map steps to services and verify results through backend checks, glossary alignment, and outcome observability, avoiding UI-level assertions.

What should a business glossary include for BDD scenarios?▼

A business glossary defines domain terms consistently across scenarios—customer, account, subscription, payment status. Using glossary language ensures stakeholders and engineers speak the same way, making scenarios readable, outcomes clear, and service mappings traceable to business concepts.

When should I avoid UI-level steps in BDD scenarios?▼

Avoid UI steps when testing behavior that can be verified through services or data state. UI steps are brittle and couple scenarios to interface changes. Instead, define observable outcomes—database records, API states, event logs—and map directly to services, keeping scenarios stable and reusable.