The biggest challenge in software projects, in my opinion, is defining the client’s needs. This might sound like an easy job, but if you don’t do it on a daily basis it will be a hard one. Just try to describe your preferred car to someone. Are you sure you are going to get the car of your dreams? I wouldn’t be too sure.
Describing business requirements that have to be converted into a well tested code is even more challenging. Fortunately, many tools are available to support this process. A method that is gaining more and more market attention is Behaviour Driven Development. We start to fall in love with it as well.
The basic concept of Behaviour-Driven Development
Behaviour-Driven Development (BDD) is mainly derived from Test Driven Development (TDD). In one of his posts Dan North explains his issues while coaching people how to use Test Driven Development. Step by step he found out the word ‘Test’ was causing the main misunderstanding. He concluded that developers using TDD in fact were describing the behavior of the system. Some time later the link towards business analysis was made.
BDD aims to help focus development on the delivery of prioritized, verifiable business value by providing a common vocabulary that spans the divide between Business and Technology. Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behavior of a system. Thus enabling the incremental delivery of business systems, and in particular in allowing teams new to agile development to quickly get up to speed using these extremely productive techniques.
BDD relies on the use of a very specific (and small) vocabulary to minimize miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are using the same words.
How BDD works
The BDD process looks like this:
A SubjectMatterExpert (typically a business user) works with a BusinessAnalyst to identify a business requirement. This is expressed as a story using the following template:
- As a Role
- I request a Feature
- To gain a Benefit
The speaker, who holds the Role, is the person who will gain the Benefit from the requested Feature.
To prevent people have to make something up Chris Matts rephrased the above structure a bit:
- In order to achieve the vision
- As a stakeholder
- I want something
If you are familiar with User Stories within Extreme Programming or UML Use Cases you will partly recognize the above.
The main difference is that the business value of the interaction has to be specified. When there is no real business value for a story, it often comes down to something like ” . . . I want [some feature] so that [I just do, ok?].” This can make it easier to descope some of the more esoteric requirements, meanwhile saving a lot of money on unnecessary software development.
Tools available for most software languages
Do you want to improve your TDD approach? Great. Many tools are already available to make the life of developers easier. Meanwhile the business user will start loving your way of working more and more. The test output of the test case will look very similar to the defined Use Case and will be understandable for the business user. In this way you can close the circle from analysis up to delivery. Here you will find an overview of the available tools.
Currently we are implementing BDD into several of our projects. Soon we will exchange our experiences with you. Feel free to exchange your experiences, tips and remarks with us by leaving a comment below.
1 comment
Comments are closed.