Effective BDD with Cucumber

After attending couple of events in last few months I came across the reality of our BDD world. Most of the teams that use cucumber or any other BDD tool have adopted them as QA tools. There developers or business or product people never look at these tests and are sole responsibility of QA team. Does this sounds familiar? do you do it the same way? is cucumber killing you?

        BDD is an evolution of TDD and by definition it aims to help focus development on the delivery of prioritized, verifiable business value by providing a common vocabulary that spans the divide between Business and Technology. There are various tools and frameworks that can be used to implement BDD and cucumber is by far the most used.

Before you decide that cucumber isn't the right option for you, lets analyze different reasons that make  using cucumber less effective:

1. Test written by QA team only: The biggest advantage of BDD is in enforcing more collaboration amongst different roles in projects. When developers are not writing a single feature test, then there is no behavior drive development and the collaboration is not achieved. The tests in this scenario will be regression tests and not inline with the system design. 
2. Test written only by Developers: Again we loose the collaboration aspect here but what we lose more is the user intent. QAs bring the user aspect to software testing, with QAs input we can avoid writing scenario that end user will never face and hav better user experience implemented in our system.
3. Product Owners: In an ideal scenario in BDD world we expect BAs or Product managers to write feature tests with QAs. But I haven't seen this model being successful anywhere. I haven't seen any product manager buying this idea ever. The best option to get the business intent into our tests is to have clear deliverables and acceptance criteria in our user stories. These can then be translated into feature tests by QAs and developers.
4. Regression suite: Cucumber tests are very valuable in providing feedback and they majorly serve the purpose of testing various integration points in your system. Using them as regression suite by testing all possible negative use cases will not be fruitful. The well known test automation pyramid recommends the amount of integration tests should be around 5-15 % of entire tests and this applies to cucumber tests as well. 



Automation Pyramid

5. Java script testing: With the ever rising popularity of selenium-webdriver the amount of java script testing in cucumber testing is also very much in practice. I have even seen team duplicating there entire tests to run against IE. Just because the tool supports these features doesn't guarantees return if used at large scale. Java scripts test in selenium have been historically brittle and will continue to be. The effective way is to use a Java script testing framework like Jasmine and few end to end tests in Selenium to test the UI.
6. Test Case documentation: While writing BDD tests we don't add comments to our tests as the feature tests serves the purpose of documentation. Doesn't this applies to your manual test cases? Teams use test case management systems to document there test cases, with BDD you should get rid of that as well. Cucumber features are very effective way to manage test cases that are regularly updated without any extra effort.

BDD is a great practice to make your development cycle effective and cucumber is an amazing framework for writing tests and collaboration. You just need to do it right.