Developers are different from other folk. Introverted is an understatement. My four days of silence really highlighted this.
Continue reading
Tag Archives: technical practices
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
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
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
Developers don’t have time for code reviews and unit tests
The ticket moves to “Dev Done” but there are no unit tests and the code hasn’t been reviewed. When challenged the developer says “That’s because I don’t have time for that stuff”. If I hear that I want to know why they feel they don’t have time, then I give them the time.
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
Avoid the Refactoring Branch of Doom
Sometimes I make mistakes. One of them was when I commissioned what I now affectionately call the Refactoring Branch of Doom. Doomed because it was never ending. The refactor was too big and, because it was done in a branch away from the main code base, the refactoring guys never caught up with the main development team. So I canned the doomed refactoring initiative and we did it a different way. One that worked.
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