At e2y, we integrate Behaviour Driven Development (BDD) into our testing approach to foster effective collaboration and communication among teams. A software development process, BDD enables teams to streamline the delivery of software projects by prioritising concrete, real-world examples (scenarios)that illustrate how we want the system to behave. These examples guide us from concept through to implementation.
Why does e2y use the BDD framework in our testing approach?
The fundamental reason why we utilise the BDD framework is its ability to “shift left” the development process, enabling us to write tests before actual development begins. By collaboratively creating scenarios with our BAs and Architects, BDD distinctly serves a purpose enhancing clarity and alignment throughout the development lifecycle. We consistently use this approach in all of our projects that have User Stories.
How does BDD help us foster communication and collaboration with our clients?
Other testing processes are done using programming languages and/or scripting which non-technical stakeholders may need help understanding – This can lead to misinterpretation. BDD, however, helps address this issue by providing a common language and framework for collaboration. As BDD closes the gap between technical and non-technical teams, it allows key stakeholders to be on the same page at all times. By aligning our communication with the client’s perspective, we not only save time but also avoid misunderstandings, making the entire process more efficient.
When writing the steps for these use cases, we use a common shared language to ensure that all key stakeholders are on the same page at all times. This is called Gherkin and IT establishes a common standard rule for writing these scenarios.
Scenario: Empty cart page authenticated
Given The Backoffice operator registers an admin customer
And John logs in to the storefront
When he navigates to the “cart” page
Then he should see the expected content of an empty cart
How do we run our BDD framework?
At e2y, we employ a robust BDD framework, using the widely embraced and popular tool, Cucumber, to create each individual feature. We leverage its powerful capabilities in step design, custom parameters, and table management, making it an essential asset in our testing processes. In our test projects, we rely on TypeScript as it offers a significant advantage in data management as it provides a flexible framework. So, when working with JSON or other generic data types, we can streamline the testing process. When executing E2E (end-to-end) tests, we use various testing frameworks (like Serenity or Playwright) and continuously explore new alternatives.
What software and tools do we use?
To implement an efficient BDD framework, we leverage a wide range of software and tools that streamline workflow and enable us to deliver our high-quality solutions.
- Jira – As Agile enthusiasts, we use Jira for our project management, writing the acceptance criteria and testing scenarios in a language our Clients, Developers, Architects, BAs (Business Analysts) and QAs (Quality Assurance testers) all understand, as stated previously. This ensures all stakeholders have a comprehensive understanding of what is expected of the application and helps guide us through the creation of necessary data and user profiles.. Using this approach establishes a 360-degree context framework and lays down a solid foundation for feature development.
- Serenity-JS – This is the most common tool used in our projects as it offers multiple advantages such as enhanced maintainability and a common “dialect”, allowing us to communicate and share testing context or results. The screenplay pattern has been a huge game changer in our testing structure, adding value and improving the quality of our test code. With Serenity, we can integrate Cucumber, WebdriverIO, and Playwright as runners, providing flexibility and transparency when changes are required.
- WebdriverIO – Wdio is a popular open-source test automation framework that simplifies and streamlines web and mobile application testing using the WebDriver protocol. It offers a flexible and user-friendly testing environment, and provides a wide range of plugins and integrations, making it our go-to choice for modern web and mobile automation testing.
- Playwright – It supports multiple browsers, including Chromium, Firefox, and WebKit, making it an adaptable solution for cross-browser testing. One of Playwright’s standout features, and one we particularly appreciate, is its support for automating browser contexts, including incognito mode and multiple pages within a single browser instance. Playwright has gained popularity among developers and testers for its reliability, speed, and ability to perform tasks like taking screenshots, recording videos, and handling complex scenarios in web testing.
- CI/CD – We execute our tests on our infrastructure using a variety of CI/CD tools, such as Jenkins or GitHub Actions, depending on the specific project. The entire testing process runs with every commit pushed, completing a full cycle, providing us with high confidence in the quality level of the delivered feature.
How does BDD help with automated testing?
For a QA tester, it is crucial to clearly and straightforwardly define the preconditions and actions executed that lead to a final result. As previously mentioned, BDD provides testers with a unique semantic base (language) that is clear for all stakeholders to understand. At e2y, this clarity enables us to have productive meetings with our clients where both parties can understand both the scenario and executed actions, assuring our application aligns with what is expected.
In a mature project, the benefits of BDD are much higher. By having a pre-established set of actions interacting with the app and numerous verifications readily available, these actions can be reused for new test features. However, there are some caveats. With this huge amount of steps, issues such as step duplications or overly specific steps cannot be reused which is a common pitfall even when not using BDD. One common pitfall, seen even outside BDD, involves duplicating steps or making them overly specific, meaning they cannot be reused as the project grows.
Despite the higher initial cost, investing in well-crafted scenarios pays off in the long run, offering unmatched readability and unique advantages. In projects like these, separating Gherkin’s steps from the framework is essential for success. Another thing to consider is parallelisation and how to group test suites. These factors are often overlooked in the project’s early stages, but as the project grows, in terms of both code and number of testers, reorganising becomes more complex. However, these aspects are not exclusive to BDD and are good practices in testing.
How do we handle testing across multiple platforms in BDD?
We test across multiple platforms with Appium, using either real devices or emulated ones, depending on the applications’s capabilities. Appium is a popular tool amongst testers, as it has a big community, and allows us to test real native apps, hybrid apps, or web versions on actual devices. Testing the app with real-life examples helps us to refine and improve it effectively.
Additionally, we use BrowserStack for testing multiple screen sizes and cross-platform versions of our apps. This approach gives us a full picture of our testing suite, allowing for parallelisation and accelerating our CI/CD flow.
Conclusion
In summary, e2y’s use of BDD boils down to effective teamwork, collaboration and clear planning. By using real-life examples and common language, we can verify that all client requirements are met and that all stakeholders understand the project goals. Writing detailed tests before creating software features not only enhances efficiency but also ensures we get things right the first time. Our use of practical tools (Cucumber, Playwright etc.) and thorough testing ensures the reliability and quality of our software solutions, guaranteeing client satisfaction and project success.
Image by storyset on Freepik
