I was asked “What to do in terms of training and practice when starting to use gherkin to define requirements?” Although I’ve written quite a lot of material on Specification by Example I haven’t written about how to start doing it.
Continue reading
Tag Archives: specification by example
Purpose Finding: Only solve problems you need to
Brian Williamson has commented that although “problem-solving is important and good when you are stuck. I’m convinced we are in need of some more purpose finding.” I agree and finding purpose manifests in several places in my approach.
Continue reading
Five things to do when people don’t to see the value of automation
Not everybody sees the value of automation, specifically test automation. But I believe effective software development demands test automation. What to do?
Continue reading
Who is Specification by Example for? Everybody!
I was talking to Pedro Santos on the train the other day. Pedro is my technical lead, an expert in his field and a keen advocate of automated testing and software craftsmanship in general. We were talking about Gherkin and Pedro was saying he doesn’t see Gherkin tests adding value because it doesn’t help him as a developer. Of course I disagree. The way I look at it is the Gherkin tests are not for the developers. The Gherkin tests are for the organisation – they are for everybody.
Continue reading
PMs Need a Technical Ally When Introducing Automated Testing
I need a technical ally when introducing Specification by Example and BDD. Actually I need a technical ally when introducing automated testing of any kind. Somebody to coach / mentor / encourage / explain / enthuse about the technology and how it helps.
Continue reading
Specification by Example helps even with no Automation
I’m keen on Specification by Example particularly with a tool like Cucumber to automate tests. However this style of specification is also useful without the automation. I introduced my current team to Specification by Example and, with some help from me, the customer is now using the same disciplines to define requirements to hand to a 3rd party development shop. The experiment has been very successful.
Continue reading
DRY Gherkin: When Using Cucumber, Keep Your Step Definitions DRY
When using Cucumber for automated testing I try to ensure my Gherkin uses ubiquitous language so the business and development team share a common language. But the Gherkin must also be DRY. This not only saves confusion but also saves development effort.
Continue reading
Improve Customer Collaboration with Ubiquitous language
Normally I’m quite a calm chap but I get quite grumpy when developers want to model the business domain using technical language. I believe in using “ubiquitous language” and that means using business language to model the business domain.
Continue reading
Three Amigos Meeting – Agree the tests before development starts
“Three Amigos” is what Matt Wynne calls the meeting to discuss the Gherkin scenarios before development starts. The Three Amigos involves the business, development and testing voices. However who turns up, where they meet, what they produce in the meeting, the homework to complete after the meeting, and who does that homework can all vary depending on the particular team.
Continue reading
Brakes let you go faster
Perhaps counter intuitively brakes let you drive fast. Without the brakes we would drive really, really slowly. I believe the same is true of automated tests. Something that looks like it should make you go slower actually lets you deliver code faster. As long as you’re doing the right tests.
Continue reading