Software development is an inherent social activity. Put a group of great minds together, each from their own discipline, and see how innovation can flourish. In high performing agile teams, bottlenecks are really not what one wants. And surely no ‘business bottlenecks’. A lack of innovative ideas, poorly specified epics or user stories will put the software development team machine to a grinding halt. Luckily, solutions exist that can act as catalysts or even fuel the machine: behaviour-driven development tools.
Behaviour-Driven Development, or BDD in short, is synonymous for a collaborative approach for entire agile teams and has common understanding and sustainable agility as its two cornerstones. BDD comes with a fair amount of tool support as well. The main focus of these tools is to accelerate the development process in conjunction with checking that the software that’s being developed, is right (cf. test-driven development). And this is what is very much needed. Not a single hour (minute?) of waste between the specification of (functional) requirements in user stories and the verifiable correct implementation of these requirements in well-defined acceptance criteria. This allows organizations to spend most of their precious time on actually implementing the functionality!
Whereas a plethora of tools already exists (for example this list), new tools are popping up quite frequently. Some of the tools, such as FitNesse, focus on collaboration using a wiki. This allows teams to not be dependent on an integrated development environment (IDE) to which e.g. a product owner might not have access. Other collaboration tools (e.g. Cucumber or JBehave) integrate well in IDEs which allows teams to treat the specifications just as source code (“requirements are versioned too, you know!?”). As an aside Fitness was recently brought to your IDE as well.
Within Xebia, we’ve recently spent some time on evaluating JGiven. A new star at the BDD firmament but not yet widely known. JGiven truly brings BDD to the developers. JGiven does not start with the specification in text (where example test cases are specified in nearly plain-English, ready for automation), but with the specification in Java source code. The textual specification, which can then safely be handed to the business, is generated from the Java source code. A pro: JGiven has improved maintainability over some other BDD tools. These may seem just small and subtle differences, but organizations should weigh these considerations carefully when selecting a BDD solution. At least, this shows the dynamic nature of the collaboration tool arena.
Rest assured, Xebia will continue to explore these novelties in the specification and test automation landscape! Want to join the discussion? See what we’re doing or leave a comment.
