Introduction & Manifesto
About the Author
Section titled “About the Author”I’m Dmitry, a QA Automation Engineer. I got tired of watching teams spend more time maintaining .feature files than actually testing their product — so I designed a simpler approach.
BDR keeps everything that’s good about BDD (Given/When/Then, business-readable scenarios, living documentation) and removes the part that slows you down (Cucumber, Gherkin, step definition hunting).
I’m currently open to QA Automation roles — remote, contract, or full-time.
Telegram: @DmitryMeAQA
The Manifesto
Section titled “The Manifesto”BDR transforms test automation from a “maintenance burden” into the Single Source of Truth about the product.
BDR values:
- Living Requirements over Stale Documentation.
- Behavioral Code over Tool-Specific Scripts.
- Infinite Reproducibility over Infinite Retries.
- Business Transparency over Technical Black Boxes.
That is, while there is value in the items on the right, I value the items on the left more.
Core Principles
Section titled “Core Principles”The BDR Way:
Section titled “The BDR Way:”- Write tests in Business Language. The Scenario Layer must read like a User Story.
- Invest in Reporting. The report is not just a log; it is a legal document of feature delivery.
- Separate Concerns. Technical details (selectors, API calls) live in a separate layer from Business Logic.
- Strive for Zero Frustration. Every failure must immediately answer “What?”, “Where?”, and “Why?”.
Anti-patterns:
Section titled “Anti-patterns:”- Write tests “for the tool”. If I switch from Playwright to Selenium, the Specification Layer should not change.
- Ignore “Noise”. Flakiness is a violation of “Infinite Reproducibility”.
- Hoard “Secret Knowledge”. Results must be accessible to Managers, Analysts, and Designers — not just engineers.
Why Not Just Use Cucumber?
Section titled “Why Not Just Use Cucumber?”Cucumber is a great idea wrapped in a painful implementation. The moment your team grows, you start paying the Gherkin tax:
- A developer renames a button → 30 step definitions break
- Business writes a scenario → engineer spends an hour wiring it up
- Test fails → you hunt across
.featurefiles to understand what happened
BDR gives you the same Given/When/Then structure, the same readable scenarios, the same living documentation — but written directly in TypeScript (or your language of choice). Your IDE understands it. Refactoring works. Reports are rich.
Reference Implementations
Section titled “Reference Implementations”| Language | Framework | Repository | Status |
|---|---|---|---|
| TypeScript | Playwright | playwright-bdr-template | Official |
Contributions for other languages are warmly welcomed! See contributing.
Contributing
Section titled “Contributing”BDR is an open standard. Contributions welcome:
- New implementations (Java, C#, Python, Go)
- Translations of the Manifesto
- Case studies of BDR adoption
See contributing for details.