How to increase the quality of software deliverables? BDD integration and bug challenge
In this article, we would like to share with you the experience of implementing BDD approach on projects. We have been using this approach for a long time and can definitely say that it has a lot of advantages for both business and developers.
The main benefit of BDD is that this approach improves the quality of supplies and reduces the number of bugs to a minimum, which means saving time, money and reducing stress for a client. We will take a look at a specific example of integration with our customer — a product e-commerce company from Denmark. Our cooperation began at the stage when the product had been written, so we started to implement the billing for this service.
We will talk about the implementation and benefits of this approach from the client’s point of view, i.e. business, skipping the technical aspects of implementation.
What is BDD?
BDD (behavior-driven development) is a software development approach based on behavior description. The BDD methodology is increasingly gaining attention of the IT industry as a logically correct development stage of traditional approaches to testing projects, including approaches to test automation. The current era of information technology dictates its own rules. In this technology race, the one who knows how to react to any changes quickly and efficiently wins. This is especially true for fintech, ecommerce and other domains where each delayed hour before the release may affect the overall picture of the quality of services compiled by our customers. Behavior-driven development as a practice is most often presented as next stage of test-driven development.
With the TDD approach, developers try to write code so that it can be checked without problems. First, checks that are not performed are created because there is no product that satisfies these checks. Only then the product code, that really corresponds to these checks, is written. BDD approach describes the user behavior in the form of text scripts written in a special language called Gherkin. Formally, this is one of the possible specification languages that should be used in BDD, but in fact it is the main one. If you build a development process according to BDD, then you will use Gherkin. Gherkin is a structured natural language used to describe the behavior of a system in a given scenario. The language vocabulary includes ten keywords (Given, When, Then, And, But, Scenario, Feature, etc).
What are the benefits of the BDD approach?
It is essential that BDD is used by the entire project team. Managers, analysts, development and testing teams should be ready to build their work based on BDD. To perceive BDD/Gherkin simply as an automation tool is fundamentally wrong. Of course, it’s possible to write cases in Gherkin first, and then automate them. However, this is not Behavior-driven development.
First of all, this approach provides full integration between all stages of development. No wonder it is considered one of the important practices in Agile. BDD will not only save information within the BA-QA segment, but also save time. For example, today we have accomplished something, but half a year has passed and this information is not lost. At the same time, we documented it in a simple way. Although usually it is not so easy to create, and even more so, to maintain documentation. In this case, we always have up-to-date product documentation.
Features of the BDD integration into a project
BDD starts with a business analyst. Correct specification is at the core. And, of course, analysts should be prepared to read the script in Gherkin. The language is very simple and does not require any technical knowledge, but may seem inconvenient at first. If the business is ready for integrating BDD, and we have explained to the customer all the advantages of this approach, the first task we face is the willingness of analysts to work with the framework. Business processes should be clear to all parties. If there is no business analyst, scripts can be written by the product owner, or the product manager. Sometimes, writing scripts falls on the shoulders of QA engineers in order to create acceptance criteria.
BDD in action
The web project we have been working on is a single page application, built on Angular. In this case, we use Cucumber — a framework for test automation using the BDD approach and Protractor — a framework for automated end-to-end testing. The following is a specific feature scenario that needs to be developed. The scenario is added to Jira story.
Then the story is taken into development. A developer immediately sees the scenario with all the steps by which it will be tested, and works on the execution of these scenarios. At the same time acceptance criteria is estimated. Once the feature is implemented, the developer covers the code with unit tests and writes end-to-end tests according to the scenarios. Of course, not all developers are able or willing to write end-to-end tests. Very often, an automation engineer is hired to perform this job. It depends on how the development process is built.
In our team, as a rule, the developers write such tests on their own. The advantages of integrating this approach are obvious — the quality of supplies increases significantly. Checking all E2E project scenarios is adjusted to a special “hook”. If the developed feature has affected or “broken” other parts of the project, the code will not even be sent to deploy until all the tests have been passed.
Continuous deploy & delivery with E2E and pipeline process
We have taken an important step in integrating E2E tests into the CI/CD and making E2E part of the deployment process. Integration into the CI/CD allows you to run E2E tests automatically for both DEV and QA environments to provide feedback and add insight that the system remains working even after a small change. In case the solution is broken, then you can get the information on when it happened and what change has affected it.
If projects are not very big, or there is microservice architecture on the project, all e2e tests can be performed with each deployment. This guarantees that all parts of the product work as expected, also there is no need to do smoke testing often. You can configure tests to run when one of the modules is being updated and the new version gets in the QA environment.
If necessary, the developers themselves can run tests on request. Based on the results of the launch, all project participants, from the development team to the client, receive an email with an HTML report. It is highly important that the entire project team has information on the test results. This gives confidence to the development team on the one hand and helps manage customer expectations on the other.
The development team can make changes faster, while seeing that the core business processes are working. Meanwhile, the client receives information about the quality of the project, showing that most of the problems are identified before the release. Even if the test reveals an issue and the release is postponed, then information appears about what exactly is broken and how the fixing process goes.
When there are no bugs, one has to offer a reward for finding them
Since our client’s product is related to financial operations where cash transactions take place, supply bugs are unacceptable, as can cost a lot. With this approach, we have achieved high-quality supplies with no major bugs. Of course, this is an additional overhead for developers, as it takes more time from them. Also the team’s capacity during a sprint might decrease, but it's worth it. Several times the customer has announced a challenge among all the teams, onside and outside ones, to find major bugs in releases. The winner could get about $300 for finding the most critical bug.
We made maximum efficiency of e2e testing
Since this is a web application and we are testing a web UI, we can integrate BrowserStack and perform tests for different browsers and devices! We configure continuous deploy as efficiently as possible. What is more, this approach reduces the number of QA and automation QA engineers on a project. This allows you to maximize the use of BDD, automating and expanding the testing process, but most importantly, it allows to get rid of serious bugs in the supply.
What have we gained of integrating BDD into the project?
- Development process corresponds to the business value. By setting priorities with the client, based on the value they provide, developers can deliver better results as they understand clearly the customer’s way of thinking.
- The percentage of bugs in the supply can be reduced to 0.
- Reduction of QA staff leads to decrease in development costs.
- All team members, from a business analyst to a developer, began to speak the same language.
- Up to date project documentation is always at hand.
- It is very easy to follow the development process: the scenarios are acceptance criteria at the same time, and as the task develops, the developer marks in the ticket which scenarios have already been completed.
- Improving the quality of the code and the product as a whole, you reduce maintenance costs and minimize risks on the project.
