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.
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.
It’s important to define a few commonly used terms.
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.
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:
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.
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. |
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.
We'd love to hear about your experience with test automation and BDD!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.