Hi SmartBear Community! Today's discussion will be around test automation and BDD benefits.
Check out the article below that explains the subject perfectly, and answer the questions at the end of the article. We will be happy to learn what you think!
The most active participants who provide in-depth and insightful replies will be rewarded 🎁
See participation rules and event schedule.
Understanding the Benefits of Test Automation and BDD
Teams have been automating tests for as long as software has existed. With the increased adoption of continuous integration and delivery, automated tests are becoming essential. Behaviour-driven development (BDD) is a much newer approach to developing software that grew out of Agile and test-driven development.
Most teams/organisations can benefit from test automation and BDD, but BDD adoption is much more than simply automating tests.
Test automation
It’s important to define a few commonly used terms.
- Test: An activity that gives you information about how a system is performing.
- Automation: The ability to carry out an activity without human involvement.
- Test automation: Running (and sometimes interpreting) tests without human involvement.
From these definitions you can see that test automation is a very broad term. It encompasses any activity that generates information about a system which can be run automatically.
Behaviour-driven development
BDD is a specific set of practices that lead to improved outcomes for Agile teams and their organisations. The three core practices of BDD are:
- Discovery: Create a shared understanding of the requirements through collaboration, typically achieved through a structured conversation centred on rules and examples.
- Formulation: Examples of system behaviour are documented using business terminology.
- Automation: Implementation design is guided by the automation, requiring the full participation of the delivery team before the corresponding implementation code is written.
As you can see, BDD has a much more prescriptive definition than test automation. While it does lead to the creation of some automated tests, this is not its primary goal, and the focus of the tests is usually limited to the functional behaviour of the system.
Comparison
The primary goal of test automation is to reduce the dependency on humans needing to execute tests. BDD, on the other hand, has grander aspirations – to reduce misunderstandings and rework by requiring collaborative discovery and formulation BEFORE any implementation code is written. Additionally, since the automation of the business-readable specification is inextricable from the design of the implementation, it needs to be carried out by the delivery team, not a separate automation team.
Consequently, BDD has broader impact on the team/organisation. It requires early and frequent collaboration where it did not exist before, and the full participation of the development team in automation. Test automation is less prescriptive and requires little organisational change.
The focus of BDD is specifying the functional behaviour of the system – non-functional requirements are rarely covered. Test automation is applicable to any test domain (functional or non-functional) that is amenable to automation.
To summarise:
|
|
Test automation |
BDD |
|
Description |
Any activity that results in automated tests.
|
A set of practices that helps organisations refine requirements and deliver software collaboratively. |
|
Primary goal |
Reduce the dependency on humans to execute the tests. |
Reduce misunderstandings and rework by reaching a shared understanding of a story before development begins. |
|
Organisational impact |
Little organisational impact beyond selection of relevant tools that target selected test domains (e.g. penetration, load etc.). Automated during/after implementation. |
Broad impact through increased early collaboration, a focus on using business terminology, and automation by the development team BEFORE implementation. |
Conclusion
Test automation and BDD have different goals and require different patterns of collaboration across the organisation. Adopting BDD does contribute to test automation, but that is not its primary goal.
Test automation and BDD are both valuable, but it is a mistake to think of them as the same thing – or even closely related. Most organisations would benefit greatly from applying both approaches.
Further reading
- https://cucumber.io/blog/bdd/eviscerating-the-test-automation-pyramid/
- https://cucumber.io/blog/bdd/bdd-is-not-test-automation/
- https://cucumber.io/blog/bdd/what-s-the-roi-of-bdd/
What do you think? Comment below!
We'd love to hear about your experience with test automation and BDD!
- Do you use BDD or test automation in your organisation? Have you experienced any tensions between them? Are you concerned about possible duplication of automated tests?
- Have you used the Given/When/Then keywords to write automated test scripts without first applying the collaborative BDD practices of Discovery and Formulation?
- When do you write your automated tests? Before or after the implementation code is written?
