Behavior Driven Development (BDD) is an Agile mechanism of developing software, with a strong focus on collaboration. In this methodology, all stakeholders need to be on the same page at any point of time of the Sprint, as well as the SDLC. Published in 2003 by Dan North, a technology and organizational change specialist, the concept of BDD was simple - use a common language understandable by business users as well as the technical team. This gave birth to the Gherkin syntax, which was simple to use and understand (defined by ‘given, ‘when’, ‘then’ keywords). It enabled development of code that was tightly aligned to the way end users would expect the application to behave. Even though BDD has been around for almost two decades now, it still appears to be an enigma to most organizations. There are questions around the process to be followed (as it requires a major cultural change), and consequently, its effectiveness. We highlight three major best practices that can help you extract the most from your BDD engagements:
1. BDD is NOT a process to be followed by Testers alone - it involves each and every member of the Agile/Scrum team
Yes, that’s right! BDD is often perceived as a Testing/Quality Assurance team-specific practice, where the focus is on having automated tests written first and driving the development of code later. However, this aspect is secondary. The main aspect of BDD, which makes it quality-centric is the common language (Gherkin Syntax) used by product owners, business analysts, developers and testers to jointly discuss and author the user stories and feature files. An important part of this process is a co-located team, siting together in a room and having the discussion face to face. The Gherkin Syntax allows the business to understand which features are being developed and how they will function. At the same time, developers and testers get better understanding of the business and the domain, enabling them to add more value to their sprint tasks, eliminating a lot of rework and saving a higher degree of time and effort.
2. Infuse a high degree of unit testing into your coding practices
A high percentage of unit testing is extremely critical to enjoy the benefits of intrinsic quality. For new features, unit testing ensures extreme shift left and in turn, acts as the stepping stone towards true quality engineering, enabling defect prevention rather than detection. For existing features, a sound base of unit testing allows you to get adventurous with your BDD automated tests, without much fear of cross-functional/feature impact. In a utopian quality engineering world, unit testing is taken care of by Test Driven Development (TDD), another quality assurance practice followed by developers. In TDD, automated failing unit tests are written first, followed by code to fulfill the tests and subsequently, by a refactoring phase. This makes the entire process air tight, with minimal defect leakage.
3. Build an ‘A- team’ having cross-skilled team members, working together in a ‘Centre for Enablement’ (C4E) model
To ensure seamless delivery of a high-quality app, in spite of frequent releases or irregular schedules, ensure that your team is as cross-skilled as possible, having a ‘next woman/man up’ attitude to tasks. The beauty of BDD is that it is flexible enough for any of the team members to anchor the entire process and ensure all critical tasks are carried out. Many mature organizations have developers and testers carrying out each other’s tasks interchangeably, based on the time available or the skillsets needed. A good way to promote this kind of ecosystem is to introduce a Centre for Enablement model, where a high degree of coaching is carried out based on the required skill sets for the particular sprint. The C4E is more of a ‘pull’ rather than a ‘push’ mechanism of learning, that promotes on the job training (aided by sand box environments in many cases) rather than classroom lessons. The C4E model also brings to the table a culture of communities, tribes or guilds, where like-minded members come together to discuss, learn and present on various topics which are both, ‘inside out’ (the new and hot happenings within the organization), as well as ‘outside in’ (latest industry trends, tools and methodologies).
The three points are a snapshot of the best practices observed in organizations, which have successfully implemented BDD now. These are critical to your BDD engagements, and enables high effectiveness and speedy return on investment.
Do you have any best practice in mind that you would like to share or discuss? Do reach out to me at - firstname.lastname@example.org