Designing good Cucumber feature files

Alister Scott wrote a really nice paper on designing good specifications with examples/bdd scenarios/acceptance tests – focused on Cucumber, but applicable to other tools as well. He captured how to evolve horrible scripts into something quite useful. I strongly recommend reading it, especially if you’re working with UI tests.

Now go to and enjoy!

Bug statistics are a waste of time

Lisa Crispin’s talk on defect management techniques for agile teams stirred some emotions at StarEast in early May. The idea that a team might not necessarily need a tool to track defects was, it seems, pure heresy. Luckily there were no calls to burn the witch, but many people at the conference were projecting a mix of confusion and sadness akin to a child just told that you’re taking away his favourite puppy.

Though Lisa presented cases when such tools might be useful, I’ll take a more radical approach: defect tracking tools are placebo, giving people a warm and cosy feeling that they have done something by throwing a digital coin into a fountain of wishes, while hoping for better software. Continue reading

Setting up a build pipeline in a legacy environment

At the StarEast conference in Orlando earlier this month, Kristan Vingrys, global test practice lead at Thoughtworks, presented an experience report on setting up a build pipeline in an environment with multiple development streams, 3rd party delivery teams and a mix of legacy mainframe and new code. Here are some of the interesting challenges they faced and solutions they implemented: Continue reading

A fresh perspective on the specification/script problem

I’ve been ranting, writing and teaching about the danger of using scripts as specifications for a while. This is one of the top reasons why teams fail with specification by example. I’m by no means the first or the only one to warn about this. Ward Cunningham and Rick Mugridge wrote against that in FIT for developing software. David Peterson wrote about that in Concordion Technique. Dan North recently wrote about that in Whose Domain is it Anyway. We all presented different heuristics to determine whether examples in a specification are at the right level of abstraction or not, mostly focusing on the difference between a series of steps that explain how something is done and a more direct explanation of what a system needs to do. But a relative novice was able to look at this with a fresh pair of eyes and come up with a much better way to explain it. Continue reading