Everybody likes to complete things in their own specific manner. However, when it comes to software programming, it would always be beneficial in having a set of principles for each phase of software development.
Opening the discussion and keeping various technical teams on the same note can allow software to work seamlessly. As organizations move towards coding phase they need to adjust the procedures to fit their present work processes. So what is it that can define user behaviour prior to writing test automation scripts?
That is called BDD (Behaviour Driven Development).
What is BDD?
BDD is a development process, which explains the behaviour of an application for the end user. It is an extension of TDD (Test Driven Development). In BDD, the behaviour of the user is defined and converted to automated scripts to run against a functional code. These test scripts are written in a business readable and domain specific language known as Gherkin, which ultimately reduces a risk of developing a code. Following are some of the points, which clearly outline the value of BDD.
1. BDD is not testing, it is a process of developing a software. It considers questions like ‘where to start in the testing process; what to test and what not to; how much to test in one instance; what to name the tests and how to understand when and why it fails. It is what can be called a rethinking of unit testing and acceptance testing.
2. Before BDD, TDD had tests that were developed first and failed until a functional code was arrived at. This point was when a test was considered to have passed. This enhanced with BDD, where the tests were written in a specific format.
3. Since the language used in BDD was domain specific the requirements are now more real time and meaningful, where all stake holders are on the same page, as opposed to the earlier ‘ only developer and tester friendly’ ones.
4. BDD does not change/replace traditional UI automation tools like selenium or appium.
5. In terms of test automation, it represents a presentation layer, in other words it can present data in a clear-cut manner and in a standardized format.
As you can clearly see, BDD has nothing to do with the technical side of the Testing, let us try to understand why and how BDD is important.
BDD helps bridge the communication gap between clients, developers and other stakeholders.
Collaboration – In traditional testing, nobody would recognize what part of the test/scenario was failing. With the BDD approach, everyone including stakeholders, product team and developers understand testing, making it a win-win situation for organizations.
Requirement Change Management – Traditionally, the requirements clarity were logged in collaboration tools like Jira or other project management tools. With BDD, any changes in requirements would automatically be documented as tests.
Test Management Tools – In traditional method, test management was separate and were automated and manually marked within the test repository. But, with the advent of BDD tools, static metrics such as “#” of specs, “#” of scenarios are collected automatically. Furthermore, other test metrics can effectively be expanded.
Single Source of Truth – Traditionally, requirements would be transferred from project management to test management, and finally to automation. With BDD, in a mature agile process, specs are written correctly in Jira and can serve as source of truth. This is in contrast to testers reading requirements.
Phases of BDD
The overall BDD process involves two important phases – Process insights & Tools/Technologies. Let us look in detail how vital Process insights & Tools/Technologies are when it comes to BDD process.
a. Process Insights
To benefit from BDD based test automation, it is imperative to have process overarching Planning, BDD Design and Test Automation Framework.
Planning – Priority based stories/features should be picked up for automation. Undertaking an iterative discussion helps to know what activities would be beneficial to ongoing automation efforts. For best results, effort estimation could be followed up by stabilization of test automation activity instead of the usual factory approach, if the product is still evolving.
BDD Design – It is recommended that, scenarios be designed by QA/BA rather than Quality Engineers. This is instinctively due to fact that they are owners of product quality. In addition to this, principle of collaboration mandates that, they own up this part of automation effort.
Also the scenarios should be reviewed from the point of functional flow, behavior semantics and step reusability by all concerned stakeholders – QA, BA and Engineers. Review process should be a de-facto part of design process.
Test Automation Framework – BDD design ensures that reusability is complemented by the implementation component. Standard automation and development practices must be followed to ensure efficient output.
b. Technologies/ Tools
Some automation tools that support BDD are listed below:
|Java||JBehave, Cucumber, Gauge|
Apart from automation tools, Test Management based on BDD test designs play an important role. There are tools like TestRail, HipTest, which now support BDD based test editor functionality and guarantee better integration of processes and implementation.
Once the Process insights & Tools/Technologies are in-sync, BDD automatically offers benefits:
Behaviour Driven Development helps in building quality and creating value. Instead of having tests that are only useful for engineers, BDD aims at tests useful for all. Additionally, it improves the partnership between the parties and allows developers to get a clearer scope of essential features and the customer gets a better knowledge of what will be delivered, with accurate estimates.
Nitor Infotech excels at streamlining and operationalizing BDD Based Test Automation through its ready-to-use frameworks, successfully employed strategies and efficient use of tools/technologies.
If you are interested in finding out more about BDD, write to us.
Subscribe to our fortnightly newsletter!