Test Automation engineers discuss the BDD processes for an e-Health project
Behaviour-driven development (BDD) is a relatively new approach to software development. When developing software solutions, we frequently encounter problems associated with regression testing. For example, one of our projects required 7 software developers, and we had to fully devote the entire QA team for 2-3 working days before the release. All of these engineers were completely (!) dedicated to executing the regression test plan for the entire product.
Figure 1: shows the number of defects before and after BDD integration to the project
This is an expensive approach and not one that’s particularly effective. Now that we’ve experienced its advantages, we try to use the BDD approach on every project.
Our latest project, which is connected to e-Health system development, had more than 15 IT companies involved in the development process. Programmers and test engineers were working intensely on hundreds of screens, services and sub-systems. The project’s challenges included new functionality development, integration with backend services, and regular planned deployments, in addition to urgent maintenance releases.
Figure 2: UI automate cost and effectiveness chart
Realization and launch of this type of system would have been simply impossible without full system coverage, not only in terms of unit tests but also in terms of integration UI tests. The result of our consultation with the client and the other development teams was a decision to start working on UI automation tests. Four of Diatom’s QA automation engineers worked on test scenarios and tests for 8 months.
Every morning the development team started the day with a report detailing existing issues, and the PM was able to organize all of the required processes to fix problems detected through UI automation.
It’s interesting to note that 4 separate servers were needed in order to run all of the scheduled UI tests during the night.
Our development process is as follows:
Figure 3: Diatom development process
Whenever a problem with the UI tests appears, test engineers register tickets and relay the details to a PM. This allows teams to solve major problems that come up during the development process and reduces the risks connected with delivering new functionality. We were able to make DEMO procedures more stable and less risky. In our experience, for every 15 software developers, this process required 1 scenario writing specialist and 4 UI automation engineers. Of course, manual testing is also important, and we had additional manual testers working on this project.
The BDD process also helped us resolve another problem. It was extremely hard to check system integration of the front end with hundreds of back end modules. Other suppliers were responsible for the back end and, at times, one part of the system suddenly stopped working and we weren’t able to detect the problem until it was too late. The most revealing example was when a supplier reported that its work was fully finished and integrated. During preparation for the final delivery, all systems went down as a result of unidentified problems at the most critical moment (as usual, the day before delivery). The whole team had to stop working on other tasks until the issues were identified and the problem was resolved. The UI automated test process helped solve this problem, not the day before delivery (!) but immediately after the problem first appeared. This has accelerated the problem-solving process and increased our efficiency.
Other advantages of the BDD layer
Another important aspect of the approach is that the BDD layer can be easily read, not only by technical people, like developers and test engineers, but also by non-technical workers, like software analytics specialists and managers. The greatest advantage is that the business logic of the project is described in business language, and BDD not only is concerned with the testing of the software product but also that the solution developed is the one the most closely aligned with the reality of the business specifications for the project. An ongoing issue in software development is that, even when well-written technical specifications for projects exist, developers can interpret them differently from the way they are understood from a business standpoint. BDD is resolving that problem. In addition, when analytics are used in advance to assist and verify the development of BDD scenarios, they can detect problems in technical specifications BEFORE code is developed and delivered to the product owners. This makes the software development process much more cost-effective.
Now that the system has been put into actual operation, we are 100% convinced that BDD is a valuable tool, and we can recommend that you implement it in your projects.