Enterprise BDD? What does it mean?

Software development lifecycle has different roles and responsibilities and in the last few years there has been a lot of changes. But the key personas haven’t really changed, even the roles, responsibilities and style of working did. During the traditional development approaches such as waterfall, we had:

• People from the business who had an idea how to improve the revenue generation and provide innovations to the market to gain market advantages. Those personas, we call business analyst. They defined business requirements to cover new areas of their key business processes, which were expected to be delivered by the software.
• People who did design and develop the ideas business analysts had into a piece of software. They had a defined time frame to deliver all the requirements being covered by the software product. We call these people developers.
• People who verified and checked the software which was programmed the developers against the requirements defined by the business analyst. We call these people testers.
• And there were few others, such as operations team, system and solution architects, etc. so on and so forth.

Collaboration gap between business, developer and tester

Practicing in a traditional software development approach, business, developer and tester were everything, but amigos. Being and acting in silos, without sharing the information across borders and using a disconnected tool chain resulted in the majority of the projects in delay sand failure of delivering the product.

Now looking at the agile software development approach such as Scrum or Kanban, you will find the same personas. They have changed and adjusted their roles, responsibilities and style of working and have removed the silos by collaborating more often together to deliver a better quality software to drive organizational business.

Closer collaboration between business, developer and tester through agile development.

Business, developer and tester have transformed from different silos to an agile team with cross functional responsibilities and more open minded culture in communication and implementation.

Even emotionally the business, the developer and the tester have come closerto have the same understanding, but aren’t amigos yet. Still there is room for improvement in communication and the expectation on the product being delivered.

With Behaviour Driven Development (BDD) we have targeted the right direction within software development. Using higher frequency of the feedback loopsbetween the involved personas BDD is targeting on the spot of the cost of translation. Using defined framework with keyword all involved personas can embrace BDD to speed up the pace of delivery. One language, one way of working, on understanding, results into reduction of cost of translation.

Great collaboration between the roles within the project

In a BDD practicing culture, business defines the requirements based on a predefined language called Gherkin. Gherkin has a set of keywords business can use to describe all precise content of the requirementin so called scenarios. Scenarios are defined in a featurefile.

A feature file is:

• Defined by the business, product owner, end user,etc. and contains all possible scenarios which describes the feature
• Interpreted by the tools of developer and tester.
• Providing developer and tester a set of examples which explains the scenario(s)
• Including data to be used by developer and tester
• Used by all three roles, the business, the developer and the tester.

This way, the 3 amigos can collaborate much faster to drive common understand of what is being expected, developed and verified.

BDD from the visionary perspective is providing huge advantages to an organization practicing agile approaches, by keeping the cost of translation to a minimum and the pace high of software delivered to the consumer with high quality. The challenge BDD is facing is around the technology layer — how it can be integrated and practiced by an enterprise organization. Currently there are a lot of point solutions used providing value for individual projects in an agile environment, such as:

Project A is working with:

• Visual Studio using SpecFlow (Cucumber.NET)
• Subversion (SVN) is used for source code management (SCM)
• Team Foundation Server (TFS) is used as continuous integration (CI) server
• Selenium is acting as testing tool

Project B is working with:

Project C is working with:

Project D is using again a different constellation… and so forth.

Collaboration & scalability issues within an enterprise.

Even these projects are practicing BDD, from an organizational perspective they are working completely isolated from each other. Cross collaboration approach is lacking between the projects.

This results in severe problems scaling BDD:

• Changes to feature files content such as scenarios changes arenot traced
• No workflow between the roles (business, tester & developer)
• No visibility on feature coverage(i.e. which features are already automated/implemented?)
• Different tools for different artefacts, no single source of truth
• Very poor reporting capabilities (majorly on feature coverage)

Scaling BDD to enterprise will require a different governance layer, which practically is not used today. This governance layer will

• Provide visibility across the backlog, scenario and test coverage
• Provide traceability to changed and / or refactored artefact of a scenario
• Provide quality insights & heat maps on implemented features
• Provide reporting capabilities across multiple projects using BDD
• Provide collaboration platform for the different teams
• Provide workflow capabilities between the teams and roles
• Provide one single source of record containing all documentation around the features