The monthly dose for BDD addicts… In February stories by Michael Fritzius, Unmesh Gundecha, Jeff Langr, Lyudmil Latinov & Dmitry Tishchenko …
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the January issue?)
Dear BDD Addicts,
I don’t know how much money has been spent (wasted?) on handling, testing and fixing software issues caused by the leap years. February is sometimes longer, sometimes shorter. Tester’s nightmare (or paradise depending on from where you see it). This year it was short, but for me it even felt shorter as so many things happened. Among others, I attended the European Testing Conference that was held in Amsterdam this year. Keep your eye on this conf next year! It was really good. The other important thing that our book with Seb Rose (Discovery: Explore behaviour using examples) has been released on Amazon in print! We are really proud of this and already working on the next book (Formulation), which is about writing good BDD scenarios. (If you have read or you are just reading the Discovery book, please help us and other readers by providing feedback on Amazon. Thank you!)
[BDD] BDD without automation
When we talk about BDD, we naturally assume that all scenarios will be automated. (Some even see BDD and the related tools as test automation tools…) Automation is an important element of BDD but not an essential one of it, especially if we think whether ALL scenarios should be automated. Certainly not. But thinking about illustrative examples and formulating them to Given/When/Then based scenarios might be useful, even if the scenario is not automated at the end. The post by Jeff Langr talks about this topic, including how we could communicate this to the business.
Should We Automate All of Our Feature Scenarios? (Jeff Langr, @jlangr)
[Process] Measure automation results
I am not a metric-guy, but I am aware that the results you have achieved by introducing BDD are definitely important, especially if you introduce BDD to an existing project/product. Dmitry Tishchenko summarizes a few interesting and important metrics that you might consider when increasing test automation efforts in a project. This might be also helpful to decide what scenarios we should automate.
Defining Test Automation Metrics (Dmitry Tishchenko at @A1QA_testing)
[Learn:Cucumber JVM] Speeding up Cucumber JVM scenario execution with parallelization
Slow scenarios are bad, because they will not provide quick feedback for the delivery team. There are many options and ideas for improving the speed of the automated scenarios. I would recommend thinking about parallelization once you have applied all other improvement techniques, as parallelization makes the measurements of any other improvements much harder. Anyway, parallelization is an important technique and Lyudmil Latinov gives a good introduction to running Cucumber JVM scenarios in parallel.
Running Cucumber tests in parallel (Lyudmil Latinov, LinkedIn:lyudmillatinov)
[BDD] Get more out of your BDD scenarios
I had once a lightening talk at Agile Testing Days about what other benefits you can get from your BDD scenarios, for example get performance benchmarks or generating a video from UI automated scenarios. Michael Fritzius lists a couple of other existing ideas that you can apply if you have already automated BDD scenarios.
Cucumber: Good for more than just behavior-driven development testing (Michael Fritzius, @Testzius)
[Automation] Automation “mission impossible”: Mainframes
Is it possible to use Cucumber/SpecFlow/Behat for my legacy app? I pretty often get such questions. The concept of BDD (discussing and understanding the requirements through illustrative examples and formulating them to scenarios) can be applied for nearly any projects. The automation, however, might be tough for an old legacy application. In the following post, Unmesh Gundecha shows an example about something that most of us would consider as a “mission impossible”: automating Mainframe apps. Actually it is pretty easy, as you can see!