Effective BDD with Cucumber

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 killin! 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 ri!ht option for you# lets analy$e different reasons that make usin! cucumber less effective% &. Test written by QA team only% The bi!!est advanta!e of BDD is in enforcin! more collaboration amon!st different roles in pro'ects. (hen developers are not writin! a sin!le feature test# then there is no behavior drive development and the collaboration is not achieved. The tests in this scenario will be re!ression tests and not inline with the system desi!n. ). Test written only by Developers: A!ain we loose the collaboration aspect here but what we lose more is the user intent. QAs brin! the user aspect to software testin!# with QAs input we can avoid writin! scenario that end user will never face and hav better user e*perience implemented in our system. +. Product Owners: ,n an ideal scenario in BDD world we e*pect BAs or -roduct mana!ers to write feature tests with QAs. But , haven"t seen this model bein! successful anywhere. , haven"t seen any product mana!er buyin! this idea ever. The best option to !et 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. .. Regression suite: Cucumber tests are very valuable in providin! feedback and they ma'orly serve the purpose of testin! various inte!ration points in your system. /sin! them as re!ression suite by testin! all possible ne!ative use cases will not be fruitful. The well known test automation pyramid recommends the amount of inte!ration tests should be around 01&0 2 of entire tests and this applies to cucumber tests as well.

Automation Pyramid 0. Java script testing: (ith the ever risin! popularity of selenium1webdriver the amount of 'ava script testin! in cucumber testin! is also very much in practice. , have even seen team duplicatin! there entire tests to run a!ainst ,E. 3ust because the tool supports these features doesn"t !uarantees return if used at lar!e scale. 3ava scripts test in selenium have been historically brittle and will continue to be. The effective way is to use a 3ava script testin! framework like 3asmine and few end to end tests in 4elenium to test the /,. 5. Test Case documentation: (hile writin! 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 mana!ement systems to document there test cases# with BDD you should !et rid of that as well. Cucumber features are very effective way to mana!e test cases that are re!ularly updated without any e*tra effort. BDD is a !reat practice to make your development cycle effective and cucumber is an ama$in! framework for writin! tests and collaboration. 6ou 'ust need to do it ri!ht.