UK Blog

The Why and How of BDD-friendly Test Automation

[fa icon="calendar"] 09-Apr-2018 20:05:39 / by Sailaja Chinnabuggannagari

“It doesn’t matter how good you are today; if you’re not better next month, you are no longer agile,” says Mike Cohn, one of the founders of the Scrum Alliance. Agile methodologies are increasingly finding their place in software projects worldwide.

BDD_TestAutomation

This is because agile enables enterprises to achieve early returns through faster product releases - fuelling active software development and continual improvement. Moreover, the ongoing involvement of stakeholders enables application enhancements and releases much ahead of competitors.

Naturally, you would expect testing activities to undergo some sort of change in the face of Agile development. This includes the testers mind set, practices, skills, DevOps elements and testing tools to leverage. As a result, quality assurance activities shift left in agile projects.

 

Curtain calls for non-agile Test Automation

Since testing teams rely on quick feedback from automated tests, an agile-friendly test automation framework is essential to match the pace of agile methods. Traditional, heavyweight, record and playback test automation solutions are outdated, as they fail to support agile ways of working.

Agile software development implementations use practices such as TDD, BDD and ATDD. Behaviour-driven development (BDD) is a popular agile software development practice that bridges the gap between business and IT. BDD puts the customer at the centre of the development approach and provides momentum to test automation.

 

Transcend to the Test First Approach

Within traditional software development approaches, testing is the final activity in the software development process. Testing teams working in silos create automation test scripts based on their understanding of the requirement.

Agile way of working make it imperative for business analysts, developers and testers to collaborate and define acceptance criteria. Following which, they quickly implement test automation using a test-first approach rather than the traditional test last process.

 

New Testing Frameworks for Agile projects

In traditional automation projects, automated tests derive from manual test cases. However, this is an overhead for agile teams, as Agile references user stories for better collaboration.

Agile teams use simple and structured language for designing user stories in test automation. A test automation framework that speaks a different language is burdensome. Moreover, traditional software testing tools and frameworks do not adapt to the agile way of continuous integration, continuous testing, continuous delivery and continuous deployment.

Importantly, each agile method uses a specific set of tools and platforms. For example, if software is developed using BDD, test automation should be implemented using BDD supporting testing tools, platforms and frameworks to fit into the agile process. Conclusively, a traditional, test automation framework does not solve the challenges of agile teams. An agile friendly test automation framework that blends with the chosen agile practice is crucial for reaping the benefits of automated testing.

 

Focus on Application Behaviour

In test-driven development (TDD), due attention is given to components. When tests are written for components, the tests cover the expected behaviour of the components. While the components may behave perfectly individually, this approach does not provide a holistic idea of how the components interact with each other and work in unison to deliver the intended behaviour of the application. As a result, the user might still observe incorrect behaviours.

BDD is commonly considered an extension to TDD, as it focusses on how components work together. BDD focusses on application behaviours and user needs. Behaviours are captured as user stories. The acceptance criteria is written in Gherkin, which is domain and business driven; ensuring conversations among stakeholders is easier to understand.

Business analysts, quality analysts and developers jointly write features and requirements in the GWT i.e. ‘Given-When-Then’ scenarios. ‘Given’ describes the current state of the application or preconditions for a test. ‘When’ is the behaviour or series of steps that your test will follow. ‘Then’ describes the expected outcome or assertions from your test. GWT scenarios focus on ‘business centric’ jargon over ‘test centric’ lingo. Developers and testers leverage GWT scenarios for product development.

 

BDD Test Automation Framework

In recent times, we have seen an explosion of BDD frameworks. These frameworks respond to the need for automation in agile development with free and open source frameworks supporting Gherkin. Undoubtedly, automated tests written in a human readable language foster collaboration between testers, developers and business analysts.

Adding a BDD layer to the automation framework brings benefits if the team is practicing behaviour-driven development. You can easily add a BDD layer to the existing automation code. However, you need an additional layer of code between the test scenarios and the framework. This layer translates into what is written in test scenarios in the natural language. It calls framework methods that match to that purpose.

Choose a BDD tool that is suitable for the framework technology .There are different BDD tools available including Cucumber, JBehave and more which work along with other automation tools for UI automation, web services automation and more.

At Mastek, our test automation framework, ‘Atom’ can easily be incorporated in any BDD Agile implementation. It provides the unique advantage of quick, hassle free testing, which nurtures collaboration within Agile team.

 

Importance of Design in Test Automation

An effective framework focuses on good design and clean code. I recommend a structural separation of frameworks and test packages. Create separate folders for feature files (test scenarios), step definitions and runner class within the test package. The runner class identifies where the feature files and step definition code is present. The tool engine uses the runner class information at runtime for running the test scenarios. Adding additional layers will give the flexibility needed for effective and faster testing.

This is how, neutralising the framework and decoupling it from the tests ensures a clean design. Design patterns such as the page object model allow for easy maintenance and extension of automated tests. A key reason for successful ROI is low ongoing maintenance of automated tests. Read this whitepaper to find out what design patterns are ideal for low maintenance frameworks and automated tests.

 

Topics: test automation

Sailaja Chinnabuggannagari

Written by Sailaja Chinnabuggannagari

A Test Lead, Sailaja drives the design, implementation and maintenance of test automation frameworks to facilitate delivery of automated test solutions.

Subscribe to Email Updates

Recent Posts