So why shouldn't we use BDD everywhere? Or to put it another way: Does BDD fit into every project's daily routine?<\/p>\n
The fundamental idea of BDD<\/h2>\n
BDD is a Development<\/strong>process, which can be reduced to four steps:<\/p>\n At its core, it's therefore a test-driven approach that formal requirements at the beginning of the development process.<\/p>\n In practice, lifecycle management systems can be used where scenarios are executable for both manual and automated test cases. For example, with OpenText ALM Octane<\/a> or in Jira via X-ray<\/a> the scenarios captured directly in Gherkin syntax as test cases.<\/p>\n These (formalised) requirements form a connecting unit \u2013 from business, development, QA, to infrastructure teams. Each team contributes its perspectives and thus develops a common data foundation.<\/p>\n BDD therefore requires high-quality requirement engineering and a cross-functional team.<\/strong><\/p>\n In practice, however, other constellations are repeatedly encountered:<\/p>\n It is difficult to make a general statement about the sensible use of BDD here.<\/p>\n Those who wish to live BDD should therefore consciously ask themselves the following questions:<\/p>\n When looking at common tutorials on BDD, one can quickly get the impression that Gherkin is an easy-to-use language.<\/p>\n She is too \u2013 if you stick to a few rules of the game:<\/p>\n Every requirement, every scenario, is test automation source code.<\/strong><\/p>\n Every requirement, every scenario, describes expected behaviour.<\/strong><\/p>\n 3. Each requirement, each scenario, must be (continuously) testable.<\/strong><\/p>\n BDD does not replace a test automation framework, but rather adds another layer.<\/strong><\/p>\n In acceptance testing, comprehensive workflows are generally tested. The test cases often comprise many individual steps, which are in themselves complex to automate. Even without BDD, this testing level is the most time-consuming process step within product development. Does this, conversely, mean that BDD should be foregone at this level?<\/p>\n As is often the case, it helps to look at the entire test process. If each individual process step can be tested automatically, what is the remaining risk in the overall process?<\/p>\n The focus on the process steps helps in several ways:<\/p>\n \u201eAcceptance testing\u201c can therefore be highly focused. Exploratory tests or A\/B tests with selected user groups are often more cost-effective here and cover the same risk as attempting full test automation with BDD.<\/p>\n A general answer on whether BDD is useful for acceptance testing is ultimately only possible within the specific project context.<\/strong><\/p>\n BDD connects all professional fields based on unified, formalised requirements.<\/p>\n The use of BDD is not a foregone conclusion and requires careful planning on the project. Just because the syntax appears modern and simple, it still requires continuous effort to use this level in test automation meaningfully.<\/p>\n\n
![\"Test-Driven](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/Test-Driven-Ansatz.png\")
<\/figure>\nRequirements as a connecting element<\/h2>\n
![\"Requirement](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/Requirement-Engineering-Team_BDD.png\")
<\/figure>\n\n
\n
BDD and Test Automation<\/h2>\n
\n
\n
\n
\n
![\"Test](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/Testautomatisierungsframework_BDD.png\")
<\/figure>\nBDD and acceptance tests<\/h2>\n
\n
Summary<\/h2>\n
![\"Software](\"https:\/\/www.proficom.de\/blog\/app\/uploads\/2023\/09\/software_testing_podcast_andreas_doering-1024x1024-1.jpg\")
<\/figure>\n<\/p><\/div>\n