The life cycle of applications is characterized by growing demand from users/customers, with more and more requirements and requests for changes. This context brings several challenges that organizations must imperatively be able to meet. Implementing a quality methodology capable of ensuring that the expectations of users/customers are met assumes particular importance in implementing increasingly shorter development cycles.
In the process of requirements gathering, the great challenge of projects is identifying the solution rather than the need. Usually, the user specifies what they want to see in the application (e.g. a new report, new button) instead of identifying the market or the expected behavior. And based on this requirement, it is up to the Functional and Technical Analysts to do their analysis and determine the best solution, both in terms of cost-benefit and alignment with the IT architecture/strategy. With the need identified, it is easier to define the best solution to implement in terms of business value and implementation costs.
With these ambiguities, when the requirements-gathering process is solution-oriented, and with the aggravating factor of a disparate language between the business and the development areas, the quality process seems to be the key to guaranteeing the correct understanding of all the project stakeholders.
Behavior-Driven Development:
BDD is an agile development technique that promotes the description of the expected behavior of the business process in all possible scenarios. This description is done in a common language, but in an algorithmic format, thus ensuring the understanding of both the business and the development team.
How can quality processes help in the implementation of BDD?
When implemented at the beginning of projects and at the time of requirements definition, quality processes allow BDD to be followed to describe test cases and behavior scenarios, question the business area, and identify all the behaviors that will need to be developed by the development area. These scenarios should always be described with the same language, ensuring mutual understanding by all project stakeholders.
This simple language, called by Gherkin, is composed of the following syntaxes: Given - step used to establish the precondition/context of the test scenario; When - step in which an event or action is described; Then - last stage of the test scenario that describes the expected result of the activities above. You should use a check to compare the desired effect with the obtained result; Finally, And - when the keyword statement (Given,When, Then) is insufficient and is used to add more information.
Performing multiple scenarios in the requirements phase guarantees that the development phase will be less ambiguous, allowing the development team to deliver faster and with fewer change requests. On the other hand, as the business knows before developing the behaviors that will be developed and tested, the volume of open bugs will be substantially lower due to poor requirements definition.
According to our experience, with the implementation of this framework, it is possible to guarantee reductions in the order of 30% of open bugs in the testing phase and a decrease of interactions in the development phase, to clarify doubts. Another relevant indicator is the reduction of about 50% of change requests after the Go Live.
Figura 1 Workflow Behavior Briven Development
The advantages of BDD in the automation process should also be considered. With the test cases described in Gherkin, and managed by the owners of the quality process, the automation process becomes faster and simplified, using automation frameworks that support BDD language (ex: Cucumber, Robot Framework, BDD Framework, etc).
Nowadays, it is increasingly vital that the regression battery is automated, ensuring speed in the feedback of the testing process and increasing the "coverage" of the quality team.
Thus, the interaction between the manual testers, who are owners of the quality process and guarantee that the tests are executed successfully (regardless if the execution is manual or automated), and the automation testers are simplified because they share the same language. This sharing of the same language makes creating automation faster but also reduces the maintenance process since when the test case fails, the tester can identify the reason and understand if the execution failure is due to a functional error or a need for automation maintenance.
Implementing automation based on BDD significantly reduces the automation built without any feedback on its execution. All the automation created is based on a manual test specification, and their automatic execution is always associated with that test case. This makes it possible, through ALM tools (Jira, Azure Devops), to check the number of automatic executions performed, analyze their execution and evidence.
In short, investing in the quality process and the BDD framework ensures efficiency throughout the development life cycle of an organization.
Published (in portuguese) in Pplware
