define-behaviorlisted

# Define Behavior BDD runs on three practices: **discovery** (what the system *could* do — a conversation about concrete examples), **formulation** (what it *should* do — capturing those examples as Gherkin), and **automation** (what it *actually* does — wiring scenarios to code). This skill lives in formulation and leans on discovery — as Liz Keogh puts it, "having conversations is more important than capturing conversations is more important than automating conversations." Gherkin describes what a system does for a user in problem-domain terminology — not how the system is built or tested. Writing it collaboratively establishes a shared language for talking about the system, one the whole team uses all the way down into the code. A good feature file is an executable specification anyone on the team could read and agree on, and it survives as living documentation. Each scenario is a concrete, believable example of one behavior. ## Discover before you formulate Good scenarios come out of a conversation, not a lone author. Real BDD discovery is a workshop where three perspectives meet — the Product Owner (scope: what's in and out), the Tester (edge cases and ways it breaks), and the Developer (the details each rule implies). You will often be working solo from a ticket, so deliberately play all three roles, and map what the user gave you — a ticket, user story, prose, existing `.feature` files, or related code — the way Example Mapping does: - **Rules** — the business rul