Automating Tests With the BDD Framework

Automation and frameworks have made leaps in recent years, where it all started from being something majorly developers, software developers in test, and testers keen on coding who used to do most of the automation, to today having codeless automation tools. Automation of course has helped many firms and projects in specific gain confidence, save time to market as well as being an efficient way of working. In this blog, we will recap the series that were delivered at PractiTest based on the BDD framework and automation testing and their best practices.

Let’s start by understanding the nature of the word ‘Automation’ or ‘Automated tests’-“a software testing technique that automates the process of validating the functionality of software and ensures it meets requirements before being released into production”. With Automation, we are shifting testing to the left as well as making sure we do the processes accurately on the right. Test Automation has many benefits as well as pitfalls, however, it has majorly shaken the market to remove manual testing where possible and automate a bigger chunk of the project. The question then arises how to do this and where to start from and the big WHY to do this instead of manual tests?

The reasons are pretty much simple:

• Testing everything manually can be time-consuming and costly.
• *Multi-browser, multiple devices, localization can be tricky if done manually only.
• Automation can help testers shift to the left easily by writing the test cases, designing the tests, and once the feature is ready just play ‘run tests.
• Automated tests allow testers to actually focus on another task whilst tests run and provide the result
• It has been researched and confirmed that automated tests give confidence in terms of coverage and test execution.
• When repetitive tests can be automated, then why test manually?

How to approach test automation?

Once your company or team has decided to shift to automation testing for the benefits it provides there are various things one needs to think about such as:

What approach will the team be taking?

• Design your tests and plan.
• Have all artifacts set out with the developers
• Understand the risks of automating your project.
• Involve the right stakeholders in all conversations.
• Understand whether this will be something done in-house or outsourced.

Obtain the automation tool

• Research well the tool you will acquire.
• Provide training to your teams.
• Make sure to see the product is compatible.
• Make sure you can afford it in the long run.

Set up an environment

• To ensure consistency, the development and test environment should be identical to the stage environment, whereas the stage environment should be the same as the production environment.
• Consider data as part of your test case like the location to sort data, should the data be masked, and what happens to the data after testing
• Define a set of best practices before writing test cases to ensure that they’re resistant to automated system changes

Design

• Adopt Behavioral-Driven Development if possible. Using user stories in writing testing requirements and scripts, this framework effectively puts testers and stakeholders on the same page.
• By using a data-driven approach, you can generate test cases just by changing the data stored in external files.
• Before adding any test into a regression suit, make sure to run and verify it multiple times to ensure that specific test’s quality.

Execute some tests

• Think about parallelizing tests so they run interdependently.
• Use a pipeline orchestrator or a scheduling tool to execute test cases in parallel.
• Put the application through tests under stable servers and network

Reuse tests and analyse results

• Identify slow, failing tests. Add a timer to your test run to single out tests that continuously fail or take time. This practice helps you identify the bottleneck and reconfigure these tests’ activities, therefore maximizing your testing efficiency.
• Compare test outcomes to validated reports and documentation from previous versions to expand coverage.
• Incorporate either in-tool or third-party smart test reports function for advanced test reports and better test maintenance.

Why aim for Behaviour driven development

Source

BDD (Behaviour-driven development) is an Agile software testing methodology in which the test scenarios are written in Lehman terms so the entire team can understand, without having prior knowledge of coding. It aims for the behaviours of the application avoiding any excessive code, unnecessary features, and lack of focus. If you use BDD it makes it easier to work towards Test Driven Development (TDD) and Acceptance test driven development (ATDD) all in all shifting testing to the left which is the best practise testers can be part of today.

Some of the benefits of BDD include the following:

• Faster feedback loop
• Reduced costs as you are only focusing on behaviours and not derailing into other features.
• It encourages more collaboration with stakeholders and the development teams.
• More clarity
• More of a comprehensive approach
• Agile and improved quality of tests

Now, the big question is why choose BDD over other test frameworks? This can get a little complicated, especially if all team members are researching different frameworks and getting vendors to demo their tools. This becomes very difficult to decide and increases confusion. Therefore, BDD framework could be a starting point and an easier solution to all problems. BDD has this extra layer of plain English language and Gherkin steps of ‘Given, When and Then’ and one can write code for those steps instead. It’s much easier to review and approve as well as onboard new testers to this. BDD frameworks provide hooks to insert extra logic for these concerns around steps, scenarios, features, and even the whole test suite.

Also, another important question is does BDD favour all types of testing and products? Well, it depends. If you are testing for microservices, BDD will work wonders. Furthermore, BDD is helpful as developers write code that implements the actual behaviour of a particular application service and verifies its business logic. Do not confuse BDD with TDD as these two are different however complement each other.

Conclusion

Automation has indeed been growing very positively with new tools coming out every single year. Whether you love to code or not there is a perfect automation tool out there for you, however, make sure to check on compatibilities with your product, code language it can support as well as what frameworks one can use. It is a great achievement to shift testing to the left with automation these days and make sure they run in the CI/CD pipelines as part of a release. Whichever tool or framework is selected, make sure to follow best practises always and make the most of the tool and its support as these tools are quite powerful.