May 29, 2017 at 10:49 a.m.BDD - working method or TDD in a fashionable wrapper?
Two approaches to development through testing are especially controversial - even professionals are often confused due to some methodological similarities between TDD (Test Driven Development) and BDD (Behavior Driven Development). Alfa-Laboratory senior test automation engineers Yulia Kovaleva and Anna Chernysheva talk about basic things about the similarities and differences between the two popular methods and what approach they use in the company itself.
Julia Kovaleva, senior Java developer of autotests at Alfa Lab.
Devoted more than 4 years to testing, is now developing a library of steps to scale test automation using Cucumber and Selenide.
Anna Chernysheva, senior Java developer of autotests at Alfa Lab
She worked in large e-commerce projects, participates in the creation and support of several BDD frameworks, and also engages in the implementation of engineering and DevOps practices.
- What is the main difference between TDD and BDD?
Anna Chernysheva : Understanding the TDD and BDD methods differs in different companies, we will talk about how everything works in Alfa Lab. The concepts of both approaches are similar, first tests are carried out and only then development begins, but their purpose is completely different. TDD is more about programming and testing at the technical implementation level of the product, when the tests are created by the developers themselves. BDD involves a tester or analyst describing user-defined scripts in a natural language - if I may say so, in the language of business.
- Is BDD just a buzzword or a fundamentally new approach to development through testing? What distinguishes it from TDD is the use of natural languages to describe tests?
Julia Kovaleva: BDD is really a buzzword, but not everyone knows how to “cook” it correctly. At Alpha Laboratory, we had to comprehensively approach problem solving and completely change many aspects of the functioning of the entire team, which allowed us to significantly reduce the cost of the testing process. It’s much easier to hire someone who can describe test scenarios in Russian than to find a specialist who can implement these tests, for example, in Java.
The BDD approach, together with engineering practices, allowed us to abandon the legacy documentation containing irrelevant information, and receive new documentation on the fly, store it with the project, which allowed us to bring analysts and testers closer to the code.
- Not only testers are involved in the development of BDD scenarios, is the need for automation devices still existing?
Julia Kovaleva: Of course, leaving the team only testers without automation is rather short-sighted. It will take some tools and the person who owns it to implement the technical component that the tester cannot do on his own.
Anna Chernysheva: The team’s need for a number of testing automation experts is decreasing, as there are frameworks that testers can use. The automation adds new functionality to the test framework, and it immediately becomes available to all teams.
- In addition to the traditional TDD unit tests, when using the BDD approach, behavior tests are also conducted. Is this where the differences between testing processes end or is it more complicated?
Anna Chernysheva:Everything is much more complicated, since BDD is rather a process whose goal is to reduce the cost of implementing new features. Even at the start of development, we get important artifacts. For example, documentation that is understandable to support. This documentation provides an opportunity for all interested parties to form their understanding of the product and user behavior scenarios that should be implemented during development iterations. With the BDD approach, we also lower the threshold for new members to enter the project.
- Many people think that BDD can be seen as a transition from unit-test-based development to integration-based development. But what is the situation really like?
Julia Kovaleva:We conducted such an experiment. An attempt to use BDD tools to write unit tests was unsuccessful, after some time the developer refused to write behavioral tests. When we talk about automation, BDD fits perfectly into this story, but this approach to unit testing was not worth it, it did not bring us any benefit. With integration testing, the benefits of BDD will be significant - here we look at the whole product as a whole.
- In what cases is the BDD approach used for testing and why is it better than the more traditional TDD?
Anna Chernysheva:BDD is mainly used to test the interaction of different components of the system, as it has already been said, the level of integration testing - it is behavioral and checks various business cases. TDD is used for development through unit testing directly by programmers who write code through this approach. In general, if in a simple way, TDD checks only modules, and BDD checks user scripts.
- Why did you need new BDD frameworks, isn’t it easier to format BDD into a set of recommendations for writing TDD and use existing ones?
Julia Kovaleva:BDD appeared to make the development team closer to the business, to organize a dialogue between the business, developers and testers. With the TDD approach, you need to write tests in formal programming languages. Tests and code lie in one place, it’s quite difficult to maintain, and a tester or business analyst is hardly likely to get to see what we wrote there. The two most popular BDD frameworks are JBehave and Cucumber. How to use them correctly, we will tell you at the next Heisenbag 2017 Piter conference .
Anna Chernysheva: This confusion between TDD and BDD went from a common idea for different approaches: first, tests are written, and then development is underway. With all the similarities, they are designed for different purposes and require the use of various tools.
- That is, BDD can not be considered an extension of TDD?
Anna Chernysheva: Yes, we think so. Instead of a test model, we have custom scripts that we automate in the same sprint with development. Moreover, at Alfa Laboratory, the BDD approach has also been organically implemented in engineering practices.
- QA is considered a female profession. What do you think, what is this connected with and how true is it? Is there any concept of female and male profession in IT?
Anna Chernysheva:Now they are trying to get away from this, but female thinking is more abstract, and specific details are important for men - this, of course, is all individual, but if you take Alpha Laboratory, there are a few more female testers in percentage terms. Maybe testing requires a creative approach, and girls - more creative natures?
Julia Kovaleva: You can conduct an experiment and calculate how many girls and men will come to Heisenbag.
At Heisenbug 2017, Julia Kovaleva and Anna Chernysheva will compare Cucumber and JBehave. Which BDD framework has more features? How to “cook” them correctly and what difficulties you will encounter during testing - the competition of the leading developers of Alfa-Laboratory auto-tests will be held in the best traditions of Mortal Kombat.
BDD Girls Battle: Cucumber vs. Jbehave
The full conference program is available on site .
Julia Kovaleva, senior Java developer of autotests at Alfa Lab.Devoted more than 4 years to testing, is now developing a library of steps to scale test automation using Cucumber and Selenide.
Anna Chernysheva, senior Java developer of autotests at Alfa LabShe worked in large e-commerce projects, participates in the creation and support of several BDD frameworks, and also engages in the implementation of engineering and DevOps practices.
- What is the main difference between TDD and BDD?
Anna Chernysheva : Understanding the TDD and BDD methods differs in different companies, we will talk about how everything works in Alfa Lab. The concepts of both approaches are similar, first tests are carried out and only then development begins, but their purpose is completely different. TDD is more about programming and testing at the technical implementation level of the product, when the tests are created by the developers themselves. BDD involves a tester or analyst describing user-defined scripts in a natural language - if I may say so, in the language of business.
- Is BDD just a buzzword or a fundamentally new approach to development through testing? What distinguishes it from TDD is the use of natural languages to describe tests?
Julia Kovaleva: BDD is really a buzzword, but not everyone knows how to “cook” it correctly. At Alpha Laboratory, we had to comprehensively approach problem solving and completely change many aspects of the functioning of the entire team, which allowed us to significantly reduce the cost of the testing process. It’s much easier to hire someone who can describe test scenarios in Russian than to find a specialist who can implement these tests, for example, in Java.
The BDD approach, together with engineering practices, allowed us to abandon the legacy documentation containing irrelevant information, and receive new documentation on the fly, store it with the project, which allowed us to bring analysts and testers closer to the code.
- Not only testers are involved in the development of BDD scenarios, is the need for automation devices still existing?
Julia Kovaleva: Of course, leaving the team only testers without automation is rather short-sighted. It will take some tools and the person who owns it to implement the technical component that the tester cannot do on his own.
Anna Chernysheva: The team’s need for a number of testing automation experts is decreasing, as there are frameworks that testers can use. The automation adds new functionality to the test framework, and it immediately becomes available to all teams.
- In addition to the traditional TDD unit tests, when using the BDD approach, behavior tests are also conducted. Is this where the differences between testing processes end or is it more complicated?
Anna Chernysheva:Everything is much more complicated, since BDD is rather a process whose goal is to reduce the cost of implementing new features. Even at the start of development, we get important artifacts. For example, documentation that is understandable to support. This documentation provides an opportunity for all interested parties to form their understanding of the product and user behavior scenarios that should be implemented during development iterations. With the BDD approach, we also lower the threshold for new members to enter the project.
- Many people think that BDD can be seen as a transition from unit-test-based development to integration-based development. But what is the situation really like?
Julia Kovaleva:We conducted such an experiment. An attempt to use BDD tools to write unit tests was unsuccessful, after some time the developer refused to write behavioral tests. When we talk about automation, BDD fits perfectly into this story, but this approach to unit testing was not worth it, it did not bring us any benefit. With integration testing, the benefits of BDD will be significant - here we look at the whole product as a whole.
- In what cases is the BDD approach used for testing and why is it better than the more traditional TDD?
Anna Chernysheva:BDD is mainly used to test the interaction of different components of the system, as it has already been said, the level of integration testing - it is behavioral and checks various business cases. TDD is used for development through unit testing directly by programmers who write code through this approach. In general, if in a simple way, TDD checks only modules, and BDD checks user scripts.
- Why did you need new BDD frameworks, isn’t it easier to format BDD into a set of recommendations for writing TDD and use existing ones?
Julia Kovaleva:BDD appeared to make the development team closer to the business, to organize a dialogue between the business, developers and testers. With the TDD approach, you need to write tests in formal programming languages. Tests and code lie in one place, it’s quite difficult to maintain, and a tester or business analyst is hardly likely to get to see what we wrote there. The two most popular BDD frameworks are JBehave and Cucumber. How to use them correctly, we will tell you at the next Heisenbag 2017 Piter conference .
Anna Chernysheva: This confusion between TDD and BDD went from a common idea for different approaches: first, tests are written, and then development is underway. With all the similarities, they are designed for different purposes and require the use of various tools.
- That is, BDD can not be considered an extension of TDD?
Anna Chernysheva: Yes, we think so. Instead of a test model, we have custom scripts that we automate in the same sprint with development. Moreover, at Alfa Laboratory, the BDD approach has also been organically implemented in engineering practices.
- QA is considered a female profession. What do you think, what is this connected with and how true is it? Is there any concept of female and male profession in IT?
Anna Chernysheva:Now they are trying to get away from this, but female thinking is more abstract, and specific details are important for men - this, of course, is all individual, but if you take Alpha Laboratory, there are a few more female testers in percentage terms. Maybe testing requires a creative approach, and girls - more creative natures?
Julia Kovaleva: You can conduct an experiment and calculate how many girls and men will come to Heisenbag.
At Heisenbug 2017, Julia Kovaleva and Anna Chernysheva will compare Cucumber and JBehave. Which BDD framework has more features? How to “cook” them correctly and what difficulties you will encounter during testing - the competition of the leading developers of Alfa-Laboratory auto-tests will be held in the best traditions of Mortal Kombat.
BDD Girls Battle: Cucumber vs. Jbehave
The full conference program is available on site .