Let me give the story behind this title. Myself and two of my friends and colleagues, Harsh and Valerian were travelling from Mumbai to Pune on 15th of July for ATA’s 15th meetup which was being hosted by FiServ. The meetup was supposed to start at 9:30 am. We had targeted to reach Pune before 9:00 am. July being a monsoon month in Mumbai we decided to leave Mumbai quite early around 5:30 in the morning. The cab picked me up from Airoli first and then Harsh from Ghansoli and last Valerian at the Jui Nagar bus stop. On our way we were discussing about different things. In one of the discussions I mentioned about a movie I saw previous night and how much I liked that. Immediately after that Valerian told that we liked Don (that is what me and Harsh heard). I immediately told that Don is a great movie too with Amitabh Bachan (Bollywood’s) as the lead in the same. Harsh agreed with it. Valerian then said what don he is talking about DAWN – that morning Dawn he witnessed while waiting for us on the Jui Nagar bus stop. While living in Mumbai high rises we seldom get a chance to witness DAWN. It then dawned (J) on us that the context changed and the phonetically sounding words DON and DAWN have created this confusion.
During the meetup we had an excellent presentation on “Whole TEAM approach to Agile Testing – BDD can help better” by By Shraddha Gupta and Saket Deshpande.
Their entire presentation is available on ATA Slideshare (https://www.slideshare.net/ATASlides/whole-team-approach-to-agile-testing-bdd-can-help-better-pune-15th-meetup)
Saket and Shraddha talked about Context and how BDD plays an important role in getting the context related issues resolved. In one of their slides they talked about perception v/s perspective. Please see the picture below
(reference https://qph.ec.quoracdn.net/main-qimg-73f348d1d5ee87af6955de6c53a444cf.webp)
This is where the context comes into play. How elephant parts can be perceived to be different from different folks depending on the context they are looking from. Similarly agile development team, Ops team, Testing and QA Team and the Product Owner (Business) might have their own perspective as per the context they are speaking from. Exactly like DAWN and DON confusion that happened on 15th morning among us.
If the context and perspectives are not matching it may result into key issues. Saket and Shraddha talked about the whole team approach which is really important to get this confusion out. But the confusion will not come out unless there is a formal way to get things discussed. BDD (Behavior driven development) is one such technique which come in very handy to resolve this.
There are some great benefits of BDD, other than the contextual problems that it automatically resolves. An excellent post – 10 reasons by BDD changes everything has this elucidated very nicely by Lary Apke. Here are the 10 reasons from the post.
- Communication between business and development is extremely focused as a result of common language.
- Business needs to tie directly to the code that is written.
- Developers know what test cases they should write to accommodate TDD.
- All the underlying benefits of TDD become more easily realized.
- Code is easier to maintain.
- Code is self documenting.
- Stories are easier to “groom” – breakdown, task and plan.
- Teams can be more agile.
- Developers can be trained / on-boarded easier.
- There is more visibility into team progress and status.
The top most in this list again is communication between the business and Dev team. The Dev team should now include a wider perspective and have QA and Operations too part of it. Let them all use the full power of BDD from day 1 to get things going confusion free.
In another interesting post from Rachel Davis (https://agilecoach.typepad.com/agile-coaching/2012/03/bdd-in-a-nutshell.html), the definition of BDD is explained as shared understanding. Quote from the same blog and picture below. “The B in BDD stands for Behaviour, the desired behaviour of the software to be developed. The DD part stands for Driven-Development. BDD is an approach for building a shared understanding on what software to build by working through examples. “
These differences in understanding, the contexts and confusions are some of the important reasons projects gets delayed, defects are not found until late and the overall costs gets escalated. BDD is resolving this problem and is getting popular in most of the agile and DevOps setup. Choice of tools are Cucumber with Selenium or Appium.
Here is picture from our meetup – thanks again to FiServ, Mayuresh, Rajiv, Amit and the whole ATA Community which makes learnings a fun during these meetups.
We are also running hands on BDD/Cucumber/Selenium/TDD/ATDD programs – part of CP-AAT certification programs. If you want to learn practical BDD along with implementation using Cucumber, Selenium or Appium do let us know.