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.
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.Itencompasses 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:
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.
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. Itrequiresearly 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.
Any activity that results in automated tests.
A set of practices that helps organisations refine requirements and deliver software collaboratively.
Reduce the dependency on humans to execute the tests.
Reduce misunderstandings and rework by reaching a shared understanding of a story before development begins.
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.