Effective BDD with Cucumber.doc
2
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 de li very of pr iori ti zed, veri fi ab le bu si ne ss va lue by pr ov iding 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! cucu mber less effec tive% &. Test written by QA team only % The bi!!est advanta!e of BDD is in enforcin! more collaboratio n amon!st di ffe rent roles in pr o' 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 wit h the system desi!n. ). Tes t wri tte n onl y by Dev elo per s: A!a in we loo se the col lab ora tio n 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 acc ept ance cri ter ia in our user stories. These can then be translated into feature tests by QAs and developers. . Regre ssion suite: Cucumber tests ar e ve ry va lu ab le in pr ov idin! 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 wi ll not be fr ui tf ul . The we ll kn own test au toma ti on py ra mi d recommends the amount of inte!ration tests should be around 01&0 2 of entire tests and this applies to cucumber tests as well.
Transcript of Effective BDD with Cucumber.doc
Effective BDD with Cucumber The reality of our BDD world. Most of the teams that use cucumber or any other BDDtool have adopted them as QA tools. There developers or business or product peoplenever look at these tests and are sole responsibility of QA team. Does this soundsfamiliar 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 onthe delivery of prioritized, verifiable business value by providing a commonvocabulary that spans the divide between Business and Technology . There are varioustools and frameworks that can be used to implement BDD and cucumber is by far themost used.
Before you decide that cucumber isn"t the ri!ht option for you# lets analy$e differentreasons that make usin! cucumber less effective%
&. Test written by QA team only% The bi!!est advanta!e of BDD is inenforcin! more collaboration amon!st different roles in pro'ects. (hendevelopers are not writin! a sin!le feature test# then there is no behavior drivedevelopment and the collaboration is not achieved. The tests in this scenario willbe re!ression tests and not inline with the system desi!n.
). Test written only by Developers: A!ain we loose the collaborationaspect here but what we lose more is the user intent. QAs brin! the user aspectto software testin!# with QAs input we can avoid writin! scenario that end userwill 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 modelbein! successful anywhere. , haven"t seen any product mana!er buyin! this ideaever. The best option to !et the business intent into our tests is to have cleardeliverables and acceptance criteria in our user stories. These can then betranslated 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 pointsin your system. /sin! them as re!ression suite by testin! all possible ne!ativeuse cases will not be fruitful. The well known test automation pyramidrecommends the amount of inte!ration tests should be around 01&0 2 of entiretests and this applies to cucumber tests as well.
Automation Pyramid
0. Java script testing: (ith the ever risin! popularity of selenium1webdriverthe amount of 'ava script testin! in cucumber testin! is also very much inpractice. , 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 usedat lar!e scale. 3ava scripts test in selenium have been historically brittle and willcontinue to be. The effective way is to use a 3ava script testin! frameworklike 3asmine and few end to end tests in 4elenium to test the /,.
5. Test Case documentation: (hile writin! BDD tests we don"tadd comments to our tests as the feature tests serves the purpose ofdocumentation. Doesn"t this applies to your manual test cases Teams use testcase 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 testcases that are re!ularly updated without any e*tra effort.
BDD is a !reat practice to make your development cycle effective and cucumber is anama$in! framework for writin! tests and collaboration. 6ou 'ust need to do it ri!ht.
