Behavior-driven development (BDD) is about implementing an application by describing its behavior from the perspective of its stakeholders. This approach is based on the continuous conversation and collaboration between key stakeholders and feedback from a customer. There are a lot of advantages to this methodology, but there are also a lot of challenges you can encounter during the implementation.
During my career as a QA consultant working across different types of IT projects, I've encountered common reasons why attempts to introduce BDD failed. Here, let’s look at some of these reasons so you can be aware of typical hindrances and go into your BDD adoption with plans to avoid them.
1. Insufficient budget
The transition to BDD—as with any other change to the software development lifecycle—requires not only new development and testing processes, but also a monetary investment. You need to train business people and engineers on how to communicate better, elaborate a domain-specific vocabulary and ubiquitous language, start or adjust your test automation, and implement test-driven development, and all of these new initiatives require money.
2. Size of the team
BDD requires complete specification before the sprint starts. Typically the team collaboratively discusses the requirements and distills them into executable scenarios (tests) using the domain-specific language for each particular feature, before the development iteration of the sprint starts. All this upfront work could be an issue for small teams and rapid projects, and the extra effort can slow them down without paying off.
3. Poor outside feedback
Staying in touch with customers and domain experts may not be a problem for some organizations, but for many, this requirement of constant contact with outside people can cause delays. In cases where feedback is a must-have to start a new user story in order to improve current behavior of the functionality, if the relevant domain expert is unavailable at that time or you are waiting for the customer feedback to be analyzed, development can be slowed down, forcibly refocused, or even stopped.
4. Lack of QA with coding skills
BDD is a high-automation methodology, so coding skills for QA engineers is a must. If you already have test automation in place then it should not be an issue (especially if you practice test-driven development or acceptance test-driven development), but many organizations struggle to move to BDD because they don't have the resources for automation engineers or because their QA engineers only know how to do manual testing. If your QA staff needs coding skills, before you attempt BDD, you could organize training opportunities and transform your manual QA efforts into a test automation process. Another option is to hire some senior test automation engineers who will be responsible for building and supporting a testing framework and writing low-level methods (bricks) that other engineers can use to write automated tests on a higher level.
5. Minimum business logic
I have witnessed several failures in projects where the decision has been made to start BDD but the projects were UI only, lacking a complex business logic. Keep in mind that BDD applies to projects with sufficient organizational and domain complexity, which can cause problems in understanding or communicating requirements from a business domain perspective. BDD does not provide a lot of benefits for UI-only, purely technical problems where the key complexity is not in understanding or communicating.
6. Too many meetings
Additional workshops and meetings should be scheduled in order to facilitate collaboration around the stories and features. But don't invite everyone to every single meeting—only ask one representative or expert from each department (product owner, business analyst, QA, dev, etc.). To minimize the time you spend in meetings, the BA should be prepared by sending the list of stories to be reviewed to the team ahead of time, writing some basic examples or scenarios to start the discovery, and making sure each feature has sufficient logic (and changing the text if not). Engineers should prepare by reviewing the list of stories for the meeting and coming up with a list of clarifying questions.
7. Bad planning and unrealistic expectations
Based on my experience, most managers see BDD as a silver bullet for all issues and expect to get results immediately. But as with any new process, adjusting to it takes time. BDD also requires changes to all stages of your software development lifecycle: requirements creation, requirements analysis, development, and testing. To take real advantage of BDD, you have to establish a sufficient basis first with a ubiquitious language vocabulary, scenarios, and test coverage. If you don't share this vision with stakeholders in advance, you could be in trouble.
8. A highly distributed team
Agile methodologies work best when there is fast, frequent communication among all stakeholders in stand-ups and other meetings. Some agilists believe that BDD only works when teams are 100 percent collocated, but based on my experience, you can achieve strong collaboration with distributed teams—if we’re talking about one or two time zones. It starts to get trickier when team members are separated by more than a couple of hours, especially when QA and dev are in different time zones. It gets difficult to pick a time when everyone can be effective in a meeting, not even taking into account possible language or culture barriers too. BDD is all about communication, collaboration, and feedback, so if one of those aspects fails, the whole concept fails.
9. Inadequate communication
I can't emphasize this enough: Communication up front and often is vital before and during your BDD implementation. If your culture is one where business people and engineers do not communicate with each other at all or often enough, the transition to BDD will be difficult. It is hard to fix these habits because resistance to change is part of human nature. Plus, engineers tend to look at the world differently from non-engineers. They are usually extremely logical, pragmatic, and direct. They’ll have to work on talking often with the business side, speaking up in meetings, and reaching out to communicate progress and roadblocks.
10. Treating quality as solely the testers’ responsibility
I worked for some organizations that thought BDD is only writing Gherkin syntax autotests, and that’s it—just writing some automatable tests without workshops or scenarios reviewed with the business in advance. There were also cases where management thought that developers shouldn’t be writing tests at all because it should solely be done by QA, which is wrong in general but especially in regard to BDD.
BDD is useful when testing is not the responsibility of just the QA engineers. Domain-specific language is useful when people in business and the QA and dev engineers collaborate and contribute to defining, creating, and maintaining functional test cases. If nobody other than testers reads these scenarios, from a testing perspective, BDD just looks like extra overhead.
11. Inconsistent formatting for BDD scenarios
Part of good communication is making sure everyone can understand the BDD scenarios, so how you write them matters. Keep these three don'ts in mind.
- Don’t use UI controls in your steps. Stick to the business logic of your app instead of focusing only on the user interface.
- Don’t mix more than two domains in one scenario. If your scenario describes the functional behavior of the app it does not include performance or visual validations. Some people try to embrace everything by validating everything on every screen of the application (including security, performance, text, and style of elements) in one functional automated test scenario. A good BDD scenario should be specific.
- Don’t use too many steps in one scenario. A good BDD scenario should be short, with fifteen steps max and ideally no more than eight. Otherwise, it will be difficult to understand what the scenario is for, it will be hard to maintain, and the test could fail before reaching the functionality it was intended to test due to some problems in previous steps.
BDD is a powerful approach, and in the right hands, it can save your project a lot of money and make your customers happy. However, BDD can be hard to adopt. It requires changes to all processes, so an external coach with experience in BDD can be a good idea, with the support of management.
The main thing to keep in mind is to have realistic expectations for your BDD adoption. Don’t expect it to be a breeze, and don’t expect it to fix all your problems immediately. Knowing is half the battle, so be aware of these eleven common stumbling blocks to BDD implementation and outline plans to mitigate them beforehand, and you’ll be able to start reaping the benefits of BDD sooner.
