" This is not a linear process, but a cycle that repeats itself throughout the project. In mature teams, you will see all of these activities at various points within each Sprint. "
Behaviour-Driven Development (BDD) is a software development process that manages both business interests and technical insights. Customers talk about the business in terms of scenario examples, this is an effective way to articulate business needs, identify invalid assumptions, and ensure that all angles have been covered. This, in turn, helps avoid defects and rework throughout the rest of the process. User experience experts may also get involved at the requirements discovery stage to help better understand the users of the future system.
SA, DEV and QA teams express business requirements in terms of features. However, they place a special importance on understanding (and making sure the team understands) the business value and motivation behind each feature. The described scenario stories is a way that emphasizes the business requirements and the value to be delivered.
First and foremost, we will focus on how the feature should work out in the end. For example, in order to submit a leave application form online, the outputs might include:
• An application form is posted to the HR department.
• The number of days’ leave and type of leave will also be sent to the HR Department/ Team Leader via email.
• The number of days’ leave will be reduced from the type of leave respective.
Focusing on the outputs helps to focus the efforts on making the feature work. This process ensures that our software will always satisfy the conditions imposed at the start of the phase.
Once the outputs are understood, the team will often use story mapping, process mapping, or other similar techniques to understand the flow through the system. This helps identify the fastest way to deliver a usable feature and also makes sure that no steps are forgotten.
The team members who will be working on a particular feature or story get together to discuss the detailed requirements. This typically involves in the least a business representative (BA), a developer, and a tester. The goal of these sessions is for the team members to get a deep understanding of the business rules and acceptance criteria for the feature and to actively uncover any previously missed complexity or risk that might trip up subsequent development efforts.
The executable specifications are now ready to be tested. This automated testing can be done by engineers, developers, or as a collaboration between the two. In all cases, automation work tends to start as early as possible in the development phase and is typically done in parallel or slightly after the development work.
The goal of Behaviour-Driven Development practices is to deliver more valuable features to the business sooner and at a frequent pace. By combining BDD and automated acceptance criteria, teams can demonstrate a clear traceability between what was the output delivered (and tested to work) and the requirements that were discussed initially.
The automated testing is mandatory to display the fulfillment of requirements in the acceptance criteria. In other words, the development is not completed until the software is tested and passed the acceptance criteria. This clear objective based planning & testing reduces the number of defects that need to be fixed after the sprint is finished and developers can focus their efforts on implementing new features.
A regression test suite is the set of tests designed to ensure that the software is accurate and correct after the software has undergone correction and changes. The regression test suite is organized in terms of features and capabilities, can then act as a form of functional documentation, describing not only what the system does but also what business goals it is trying to achieve.