Should you consider BDD for your team? I just wanted to share my experience with BDD, which you could consider as food for thoughts:

• Why? – How often does your development team ask the business team why certain feature is important? More importantly, why now and how much of it is enough? In my experience with BDD, the approach naturally lends the teams to have a constructive discussion about this. I’ve seen this leading to a genuine collaboration between business and development. In short, BDD helps getting the right people to discuss the right amount (depth) of things at the right time.
• Better commitment and buy-in: BDD lays very heavy emphasis on Business value. It forces the Business to justify the priority by showing concrete value. Also it helps the development teams to embrace the prioritizes set by Business, because they understand the thinking process much better. Interestingly, I’ve noticed that teams that practice BDD, I rarely see either sides throwing their weight around to push their pet features through. Also due to the focus on value, rarely I find teams building useless feature for the sake of proving productivity.
• Ubiquitous domain language: By working together, the business team & the development team build a shared understanding by using tools/techniques like product discovery, story maps, user stories, acceptance criteria and scenarios to create an ubiquitous domain language. The ubiquitous language is usable/understandable not only by domain experts, but also by every member of the team. This goes a long way in reducing the complexity in the domain and making the barrier-to-entry much lower for new members.
• Right focus: BDD can help you focus on the user’s needs and the expected behavior instead of jumping ahead and getting caught up in implementation details upfront. Also I’ve seen teams which are new to Test Driven Development (TDD), seem to focus too much on “testing” missing the point. BDD helps the teams focus on system’s behavioral aspects rather than focusing on testing your implementation. Over the years, we’ve learned that up-front analysis, design, planning and test planning, all have a diminishing return. In my experience BDD helps strike the balance.
• Evolutionary Design: Agile (eXtreme Programming in particular) has killed the notion of “fully-specified, completely-detailed-out requirements upfront.” It is a well accepted fact that we won’t be able to figure out all the requirements when we are starting off with a project. BDD, at its very crux, embraces the fact of evolving product understanding and hence helps your system’s design evolve to keep pace with the changing needs.
• Breaking the knowledge silos in distributed team: Having worked with distributed teams for over a decade, due to the distributed nature, one common problem I see is domain knowledge gap between the team members. Esp. teams which are away from the real business, have a hard time understanding and questioning the business requirements. Usually there are gaps or misunderstanding, leading to rework and frustration. Even if your team is not distributed, you might be familiar with the problems of knowledge silos. I don’t think BDD alone solves this problem, but at least it encourage teams to work more closely and reduces the gap. It also encourages a generalizing specialist attitude in team members, helping with other eXtreme programing practices like pairing, collective ownership, etc.
• Greater ROI: Behavior has a much longer shelf life than your implementation and implementation related documentation. Also as the business rules change, BDD captures it better than it being lost in documents and code.
• Predictability & Confidence: Also in my experience working with teams using BDD, I see that they have much better (or at least feel they have better) predictability and confidence in their work.

What’s your experience?

Also to clarify, what I mean by Business team and Development team, my definitions below:

Business Team: Folks who focus on “Are we building the right product.” This usually includes the following roles: Product Owner/Manager, Stakeholders, Product Designer (User Experience), Subject Matter Expert, Business Analysts, and so on.

Development Team: Folks who focus on “Are we building the product right.” This usually includes the following roles: Architects, Tech Leads, Developers, Testers, Graphics designers, Database administrators and so on.

Another great knowledge share from the Digilty/Mastek team. The latest webinar focused on Behavior Driven Development in automated testing using the Cucumber framework. Here are the top five takeaways from the session, led by Tripti Mittal:

What is BDD

BDD (Behavior-Driven Development) is a fusion and improved enhancements of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development). Unlike TDD where testing & development are conducted in isolation, BDD is a collaborative exercise that involves product owners, business analysts, testers, and developers which helps to ensure that all project members understand precisely what needs to be done and implemented.

Agile & BDD

BDD can be used in non-agile projects. They are techniques to design requirements and test cases, which can be automated. Often they are used in agile software development because they provide a fast response sequence for requirements and code under development. In addition, since Agile development does not have a separate testing phase, BDD helps in introducing automation testing at an early stage enabling teams to easily protect themselves from costly regressions.

A BENEFIT OF USING BDD

BDD adds structure and objectivity to requirements and acceptance tests by adding real data in Gherkin format. This allows teams to communicate better and focus on real world examples and not on abstract and imperative requirements. Thus bridging the gap between Business and IT.

CUCUMBER FRAMEWORK

Cucumber is a tool that implements a behavior driven design workflow. It does not care about the name or the description but rather the purpose is simply to provide a place where you document important aspects of the feature such as a brief explanation and a list of business rules.

Organizations falsely believe that popular BDD tools provide the secret ingredient that will radically change the way that they define, build, and maintain their automated tests. We need to understand that these tools are simply a concept layer that allows us to better define our needed tests up front and minimize redundancies in our tests. It will not fix problems like:
• Not enough testers with the know-how to build automation.
• Inability to build robust and complete test coverage, whether it is automated or manual.
• Applications with low testability (i.e. lacking API’s for service level tests, improperly named
objects, old frameworks like Flash)