{"id":22,"date":"2019-06-17T09:57:20","date_gmt":"2019-06-17T09:57:20","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=22"},"modified":"2019-07-02T10:44:09","modified_gmt":"2019-07-02T10:44:09","slug":"basics-of-bdd-testing","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/","title":{"rendered":"Basics of BDD testing"},"content":{"rendered":"\n
Everyone likes to get things done their own way, but in software development, it can be helpful to have some guiding principles for the way your organization handles each part of the software development lifecycle.<\/p>\n\n\n\n
Opening the conversation and keeping different teams on the same page means that software is shipped seamlessly. Additionally, as these organizations start shifting left, they have to adapt those processes to fit their current workflows.<\/p>\n\n\n\n
Let’s look at one method that’s becoming increasingly popular and discover how it’s helping different teams ship state-of-the-art software.<\/p>\n\n\n\n
You might be hearing a lot about Behavior-Driven Development<\/a>, or BDD, lately. BDD is an extension of Test-Driven Development (TDD) that emphasizes developing features based on a user story and writing code that provides a solution to real problems.<\/p>\n\n\n\n This means that the client or product manager communicates a vision, and the developer then needs to define those behaviors to meet stated business goals. Then, the tester comes in to see if this new feature meets the “why” behind the code.<\/p>\n\n\n\n For example, if a client said they found in their research that they had a lot of older users handling their application and they need a way to make it more accessible, your move as the developer following a BDD model would be to consider how this behavior changes which features you would add to the application – perhaps larger fonts and easily clickable items.<\/p>\n\n\n\n Of course, a big part of BDD is being able to determine what different behaviors mean for the application and requires keeping an open conversation with key players to correctly identify the right additions or fixes.<\/p>\n\n\n\n BDD places a heavy emphasis on team collaboration and cross-functional workflows. Making sure these user stories and behaviors are communicated from the business side to the technical delivery is an integral part of successful BDD.<\/p>\n\n\n\n Like TDD, BDD advocates that tests should be written first, which is good for having high test coverage. In BDD, you’re building up an accumulation of acceptance tests, which means that often teams that follow it use test automation<\/a> and CI\/CD<\/a> tools.<\/p>\n\n\n\n While the misconception of test automation taking testing jobs arises, the BDD mindset further proves the importance of testers in the SDLC. Not only do testers have to make sure the code works, but they also have to consider the problems that it’s solving.<\/p>\n\n\n\n This means testing in BDD is testing the functionality of the features as well as the initial behaviors it’s being built for. Instead of just thinking about whether a certain function works, testers must think about it in the context of the scenario it’s being used in.<\/p>\n\n\n\n Cucumber<\/a> is an open source tool that supports BDD. Not to mention, it reached 5 million downloads in its first 3 years, so it’s safe to safe it’s a popular choice among testers.<\/p>\n\n\n\n By letting contributors define application behavior in plain English through Cucumber’s Gherkin language, it’s used to communicate with software stakeholders how the application is supposed to act and respond, what behavior defined that, and why.<\/p>\n\n\n\n While the Gherkin text is based on the code in the application, anyone can read and understand it. The purpose of this is to clarify different steps in the development process to everyone involved with the release of the software.<\/p>\n\n\n\n This adds a layer of detail that communicates the benefit of added functionalities to the client in a way that tells them whether or not it meets the original vision and answers business problems with a clear solution.<\/p>\n\n\n\n By keeping the flow of information open as the application reaches different stages in the SDLC, it’s easier for anyone involved to pinpoint where someone might have taken a wrong turn and identify which elements may need to be changed.<\/p>\n\n\n\n This is a very high-level understanding of BDD. To learn more about BDD and Cucumber, listen to The Big Ideas Behind BDD<\/a> from SmartBear’s recent meetup.<\/p>\n\n\n\n If you’ve been hearing all about the benefits of BDD from your peers and colleagues but don’t know where to start in bringing actionable items back to your organization, you’ll want to tune in to this recording.<\/p>\n\n\n\n Cucumber co-owner Seb Rose will be your guide in understanding where you and your team stand in the industry shift left, and how you can take the best parts of the BDD process to improve your workflows.<\/p>\n\n\n\n https:\/\/dzone.com\/articles\/the-basics-of-bdd-in-testing<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Everyone likes to get things done their own way, but in software development, it can be helpful to have some guiding principles for the way your organization handles each part of the software development lifecycle. Opening the conversation and keeping different teams …. Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"class_list":["post-22","page","type-page","status-publish","hentry"],"yoast_head":"\nTesting and BDD<\/h2>\n\n\n\n
Cucumber<\/h2>\n\n\n\n
The Big Ideas Behind BDD<\/h2>\n\n\n\n