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
Tag Archives: technical practices
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
Research on Pair Programming by Professionals
Research on Agile technical practices are few and far between. The research that exists often uses students as the test subjects so doesn’t necessarily reflect professional practice, particularly not by senior professionals. In 2006 I got my company of the time involved in some research on pair programming. What was different about this study was that the subjects were professional developers. The results were interesting as, in general, they didn’t bear out claims that pair programming improved quality or speeded up development. But pairing does take a lot more effort. This is why I am selective about encouraging pair programming, restricting my active encouragement to discovery mode.
Continue reading
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
Pair Programming is Best in Discovery Mode
Pair programming is one of the technical practices from Extreme Programming (XP). I have observed that pair programming works best when either member of the pair are in discovery mode. If there is little discovery going on, by either of the developers, there is little point in pairing.
Continue reading
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
4 Objectives for an Automated Test Strategy
I recently explained to my team the objectives our automated test strategy had to fulfil:
- Provides “living” requirements documentation
- Results in a comprehensive regression test suite
- Ensures high functional coverage
- Runs fast for developers
Agile Requirements Snail: Feature to User Story to Scenario
The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.
I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.
The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:
Agile Requirements Snail