For the past 10 years as a QA Engineer, I was used to writing test cases using traditional techniques that involved a process of planning, design, execution, reporting, and analysis of results. I remember using tools such as Test Link and SpiraTest which were very useful because I could track all my test cases effectively.
However, such traditional techniques were not completely aligned with the QA Agile process. As you might know, Agile QA aims to identify customer requirements and anticipate scenarios through early testing and sprints. This means that the analysis, design, implementation and testing phases take place under a period of two weeks. With traditional techniques, test cases didn’t cover all the customer requirements and test scenarios, because such techniques didn’t offer the same velocity and dynamic that Agile provides. As a result, my team decided to try a different approach called BDD (behaviour driven development).
What is behavior driven development (BDD)?
BDD is an approach that emerged from test driven development (TDD). TDD focuses on writing a test case that focuses exclusively on functionality, while BDD aims to test an output under a given condition and from a user-focused approach. According to Christine Wong, “BDD is a software development process for teams to create simple scenarios on how an application should behave from the end user’s perspective”. BDD enables me to obtain better case results for a feature and also for the automatization of tests.
In addition, BDD improves communication between stakeholders and developers because it uses a common language. Particularly for BDD test cases, this means all parties involved can easily understand how the application behaves and the team is able to meet both technical and business needs.
A few years ago, my team and I put BDD into practice for an internal project. The experience of applying this methodology was amazing because, as we used Gherkin language, the structure, syntax, and format to create the user stories were much clearer and easier to understand for both QA engineers and developers. For instance, we used Gherkin to write narrative user stories as well as scenarios.
This approach allowed us to improve our software development process because the test coverage was increased and the team found more bugs before releasing the software.
The importance of the behavior driven development cycle
In order to implement the BDD methodology and BDD test cases successfully, we should follow a set of steps that include: define business needs, create requirements, elaborate scenarios, carry out tests and get feedback to track progress and document the application. The graphic that follows is an excellent overview of the general structure, however we adapted this structure when applying it to our software development process.
After following this process we were able to better implement and develop features, detect bugs and define every aspect of the scenarios. I would estimate that thanks to BDD we improved our processes and results by 50%.
Currently, we are launching a pilot test in order to apply BDD. However, as it is a new approach it poses a number of challenges. It’s a new framework not only for the client, but for several people in the team as well, which is why we need the collaboration of stakeholders, product owners and engineers. Our experience here at Belatrix is thus invaluable, as we’re able to guide organizations in their journey to adopt BDD. The pros of BDD are clear- from aligning software development to the end user’s needs, improving collaboration between different parts of the business, to lowering costs because you’re building better quality software the first time.
Conclusion: Give behavior driven development a chance
Given the increasingly competitive landscape, businesses want to improve their software development processes. BDD offers a new approach to write features while improving the communication between developers, QA engineers and business stakeholders. As a result, we are able to prioritize both technical and business requirements and meet the customers’ needs. I have seen the difference before and after BDD implementation and I recommend giving it a try to improve your team’s processes.
BDD in Action: Behavior-Driven Development for the whole software lifecycle — by John Ferguson Smart