BDD Believer

I’ve been in Automation for more than 10 years. I consider myself a hardcore automation engineer, and have always thought that to truly get automation done you need programmers…that’s just the bottom line. Over the years, several different methodologies, processes, and tools have come and gone in an attempt to enable non-programmers to build automation suites. Most of these, such as record and playback, scriptless automation, etc have cons that outweigh the pros.

I’ll be perfectly honest, I threw Behavior Driven Development (BDD) in that boat as well. I viewed it as just the buzzword of the day that managers and executives were throwing around and mistaking for some magical solution to gain automation for free.

One of the agile teams I’m working with has a business analyst and development team that have already adopted the BDD approach for communicating requirements. Acceptance tests are written in Gherkin, and unit tests are being automated using Java and Cucumber. So when I was tasked with developing a QA automation strategy, it was a no-brainer to get on board, have QA jump into the conversation, and adopt this approach as well.

There were no programmers on the QA team, so that definitely played a part in my decision to adopt BDD in the automation strategy as well. We needed to be able to succeed at automation with only half of my time allocated to the team as an automation resource. Cucumber’s feature files were the answer! The team was already using Gherkin to communicate about the stories, so we simply added the step of the dev and QA analysts writing these scenarios in feature files which could then be executed by an automation framework.

This worked beautifully! I spent my time enhancing the automation framework to provide the hooks needed to execute the scenarios, and the QA analysts were able to contribute to our automation goals simply by writing their scenarios in the Gherkin language.

As the saying goes, numbers don’t lie. The results we had in our very first sprint of incorporating BDD into our automation strategy spoke volumes:

• 120% of committed story points completed
  • 61% increase in number of story points completed vs. previous sprints
  • 89% increase in number of stories completed vs. previous sprints

Here are the factors that I believe played a significant part in the increase in productivity:

• Scenarios written in Gherkin took less time to write than the traditional long-form scenarios that detail every single step and expected result
• Scenarios were executed by the automation framework as opposed to manually, so the runs were shorter.
• On that same note, the automation framework executed the scenarios at the service layer, as opposed to on the UI. Much quicker and less brittle!
• Misunderstandings were identified much earlier in the process, so there was not as much rework as in previous sprints.

So, yes, I am definitely a BDD believer now. Would I advise all teams to adopt this approach? Probably not. I’m all for using the best process that works for the given team based on the given circumstances. In this particular scenario, BDD was the perfect solution.

I’m still very new to using BDD principles within automation and am learning as I go. If you have any good resources, feel free to drop them in the comments!