Interview with
summary
BDD is about using concrete examples to surface risk and drive development, not about test automation frameworks like Cucumber or JBehave. Observe that teams focus on tooling, produce too many scenarios that bloat documentation, and mix UI, implementation and domain language making specs brittle. Prefer feature injection and context questioning to identify stakeholders and uncertainty, prioritize the interesting scenarios at the top, and consider a tiny DSL instead of an English-framework-heavy setup.
AI-written summary · about
chapters (4)
related talks
42mTo TDD or not to TDD: that is the question!
28mTDD: When the thrill has gone
54mWhy Everything Is SDET’ed and Spoiled
55mShifting the Testing Role Pendulum
46mPanel Discussion: Breaking Myths About a Career in Testing
58mTDD my recipe notebook
43mTDD — Things I Learned in the Last 12 Years
20mCraft, TDD, DDD... Should I Feel Guilty for Not Doing Them?