Learning Objectives
By the end of this lesson you will be able to:
- Explain why a traditional QA checklist is hard for a business stakeholder to review
- Explain why a technical specification is hard for a business stakeholder to write or validate
- Identify the root communication gap that BDD is designed to close
Three Documents, One Feature
Picture a "password reset" feature. Three artifacts typically exist for it:
- The business requirement — a paragraph or two, written in business terms: "users who forget their password should be able to regain access via email."
- The technical spec — API contracts, field validations, token expiry rules, edge cases around rate limiting.
- The QA checklist — a list of steps like "1. Click 'Forgot password'. 2. Enter valid email. 3. Check inbox. 4. Click link. 5. Verify redirect."
Each document was written by, and for, a different role. That's the problem.
Why the Checklist Fails Business
A checklist describes actions, not intent. "Click 'Forgot password'" tells a business stakeholder nothing about what should happen if the email doesn't exist in the system, or what happens after 3 failed attempts. The checklist assumes you already know the expected behavior — it's a script for execution, not a description of the feature.
Why the Spec Fails Everyone Else
A technical spec goes the opposite direction: too much precision, too little narrative. Field-level validation rules and token TTLs are essential — but a business analyst reviewing the spec has no easy way to confirm "does this match what I asked for?" without reading between the lines of database column constraints.
The Missing Middle Layer
What's missing is a document written at the behavior level: specific enough to be testable, plain enough for a non-technical reader to verify it matches their intent. Not "click here, type there" (too literal), and not "token TTL = 900s" (too technical) — but "given an unregistered email, when the user requests a reset, then the system shows a generic confirmation message without revealing whether the account exists."
That sentence is readable by a BA, testable by a QA, and precise enough for a developer to implement against. It has no name yet in this lesson — you'll learn it's called a scenario, and Gherkin is the syntax that keeps it disciplined.
Pro Tip: The next time a bug gets blamed on "that's not what the ticket said," check whether the ticket described behavior or just actions. Nine times out of ten, it's the latter.
Key Takeaways
- Checklists describe execution steps, not intent — hard for business to verify against their goals
- Technical specs are precise but not accessible to non-technical reviewers
- The communication gap sits in the missing middle: a behavior-level description everyone can read
- BDD scenarios are designed to occupy exactly that middle layer