Dear BDD Addicts,
I have been working a lot this month on improving my scenario synchronization tool that has worked only with Azure DevOps so far, but now it can also target Jira. It was great to see that the architecture could support such a big change and the refactoring that was necessary because of the differences has been nicely protected by the different levels of tests.
The long awaited conference season has started as well and I am looking forward to meeting other folks and have some random chats. I will attend the Craft conference here in Budapest and the EuroSTAR in Copenhagen. I hope to see and meet you there.
And now… let’s see the monthly dose.
[Agile Testing] The most interesting part of computer science
I studied and learned about software development in times where testing and test automation was not valued much. We were taught that these activities can be done by anyone so I was really surprised when my first test automation solutions were not successful. It seemed it was definitely not as easy as I thought. At least if you want to do it right. Since then I have learned a lot, but I keep learning. And in the meanwhile I try to share my findings: testing and test automation can be really an exciting challenge.
The article by Jason Arbon shares the same message, but in a much better way. Really worth reading.
Testing is an Unsolved Problem (Jason Arbon, linkedin:jasonarbon)
[BDD] Test-only BDD?
I have been talking about a common BDD misconception and I have been sharing articles about it: where BDD (or rather Cucumber) is seen as a testing tool only.
I was in a meetup last week where a speaker explained their “BDD” journey. They admitted that in the current stage of the company, they cannot reach the full BDD scope, where the requirements are prepared using examples and formulated to scenarios, but they found that there was still a benefit for them to express their tests in a business readable way, so that it would be easier to review them and provide traceability of the requirement test coverage. To avoid confusion, they called their process BDT – Behavior Driven Testing. I have never heard about this term before, but it seems to exist.
I haven’t decided yet, whether giving a name to something that is “incomplete” helps or not, but certainly there are many companies where you can introduce BDD step-by-step only, and it is also clear that – if done well – tests properly expressed as BDD scenarios might bring some benefit in this stage as well. What do you think?
Behavior Driven Testing in Automated testing (Katalon Team)
[BDD] The Gherkin “Rule” keyword
I owned an open space session at the CukenSpace conference last week about the importance of the “rules” in BDD, where I shared my journey about the rules: I have been using rules for example mapping for a long time and found it beneficial, but lately I have realized that the rules are super important and useful once the implementation has been finished and the scenarios get into the “regression test” phase. It is much easier to review how a feature was implemented if you do not only have the scenarios but they are structured by the rules they illustrate. So I really encourage you to learn about rules and the Gherkin “Rule” keyword. The post by Seb Rose will definitely help!
Gherkin Rules (Seb Rose, @sebrose)
[BDD] How to understand a messy scenario?
As mentioned above, many companies use Cucumber as a testing tool that unfortunately can lead to really messy scenarios. There is a way out of this situation. The GWT challenge by Gojko Adzic and the response by Janet Gregory to it might help.
How to identify the intent of a confusing scenario? Janet’s response (Janet Gregory, @janetgregoryca)
[BDD/Perl] Testing APIs with Perl using BDD
Perl, like Python is super flexible and therefore it might be very handy for test automation. Lately there has been some activity for the Cucumber implementation for Perl so I thought it would make sense to see a concrete example, how BDD style test automation looks like in Perl. Thanks to Dragos Trif for sharing this.