Lucia Cavero-Baptista
When we talk about agile, most testers like the idea of it and what it brings to the work space - that is, working efficiently and being responsive to customers and users. However, test automation at this development speed is a strenuous endeavor.
Behavior Driven Development (BDD) facilitates the shift from manual testing to automated testing thanks to an understandable language that gets rid of complex test script syntax. It makes us rethink our approach towards unit and acceptance testing so that we avoid issues that may naturally arise.
So, how do we automate tests in BDD?
In BBD, at the very beginning of a feature file, we write acceptance tests using the standard agile framework of a user story:
·As a user
·I want to login to the shopping website with my username and password
·So that I will be able to enter the customer portal
Once the feature file has been established and agreed by the business participants, we then write the acceptance criteria to test that behavior. The acceptance criteria for a feature is written in terms of scenarios and implemented as classes. This allows for regular expressions – DSL – to map steps in a feature file to concrete actions. A scenario is written in the following format:
·Given Tom is on login screen
·When Tom enter his login credential
·Then Tom should be able to login
However, in order to deploy the test scenarios through an automation tool, we would have to translate them into code – meaning that implementation and maintenance would be in the hands of a few technical peers.
Therefore, the bottleneck that we encountered when we first deployed agile development – and which we fixed through BDD – is now present again due to coding constraints. So how can we support BDD with a no-code automation tool?
The behavior format of BDD allows you to specify each statement in a modular way. Some test tools, such as Leapwork, leverage a unique visual language that allows you to build test scenarios through modules that represent each behavior statement.
In Leapwork, creating automated tests using a BDD methodology would look like this:
1.We write the BDD test scenario
2.We log into Leapwork’s automation platform
3.We create a step-by-step flow using visual flowcharts
4.We record the flow to see if it works as intended
5.Finally, we organize the flow by grouping sections into subflows that easily describe each of the actions of our test scenario
Following the previous test scenario example (Tom wanting to log in), the final automation flow in Leapwork would look like this:
Because each action – GIVEN, WHEN, THEN – needs more than one step to be completed, we have grouped those steps into subflows (shown in purple). The following image shows what actions we find inside the “GIVEN” subflow:
Using a visual and codeless test automation tool such as Leapwork means that you can add one extra layer of visibility and understanding to the BDD process – this is because test cases are also built in a language that anyone can understand.
They can now be used both as feedback on the application’s functionality as well as documentation about what the application does. BDD places a lot of emphasis on team collaboration and cross-functional workflows, so it is very important that the test automation tool that we choose facilitates those.
The suite of unit tests continuously provides feedback to ensure that each key component is still working. This means that unit tests act as evergreen documentation and thetest suites also function as a regression safety net on bugs.
Using BDD as a test automation framework is an effective method to streamline activities in software development. It allows us to integrate test automation at early stages of product development.
This, in turn, forces critical analysis and design because both developers and testers need to fully understand the desired end-product and how to test it before developing the production code.
Thanks to this process we are able to seek the domain expertise of business and QA professionals to ensure the successful development of any software.
If you want to read more on the topic, make sure you check out our blog post on "Traditional Development vs. Behavior Driven Development".
