“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
Tag Archives: quality
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
Declarative vs Imperative Gherkin Scenarios for Cucumber
Everybody I’ve met that is new to Gherkin starts with an Imperative style of scenarios. The Imperative approach is simple and intuitive and reflects what manual testers do. But I hate the Imperative style with a passion. I favour a Declarative style of scenarios not least because a declarative style means I can test business rules. The UI is prone to change but the business rules tend to be more stable.
Continue reading
Whose responsibility is testing anyway?
I have a painfully small manual test team, sometimes 1 tester per 15 developers. The answer to the obvious question “who tests?” is “mostly the developers”. Of course this only works if you’re doing extensive automated testing including Specification by Example with a tool such as Cucumber.
Continue reading
Cucumber: Who writes the Gherkin Scenarios
Gherkin, the language used in Cucumber to write tests, is meant to be understandable by folk from the business. I haven’t encountered product owners able to write their own scenarios. And I don’t trust either developers or testers to do it on their behalf. The only people I trust are business analysts trained to write and think Gherkin.
Continue reading
Which Gherkin Scenarios go in which Feature File
I believe that you should break the link between Gherkin files and the Epics / User Stories that triggered the Gherkin Scenarios. The Gherkin files should be organised in a way that usefully describes the evolving product. You need to accept that a User Story can affect Scenarios in multiple Gherkin files. Once the User Story is done you can and should forget about it. But the Gherkin Scenarios have a life long after the User Story is gone.
Cucumber is my tool of choice for Specification by Example
Cucumber is my tool of choice for Specification by Example. I like Cucumber for three reasons:
- The specifications are written in plain English
- The supporting tools are very mature
- The step definitions are clean
Six Reasons to Adopt Specification by Example
I love the whole concept of Specification by Example. This approach ticks several boxes for me:
- Business requirements
- Concrete requirements
- Earlier conversations
- Shared understanding
- Automated tests
- Living documentation
Specify Business Rules by Example
If you are going to use Specification by Example then start by specifying the business rules.
Continue reading
Specification by Example versus Behaviour Driven Development
Personally I favour the phrase “Specification by Example” over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).
Continue reading