|
Software Quality Standard |
In Synergix Technologies, we would always do our best to ensure that the systems that we develop are of the best quality standard possible. Across the various departments, we utilized behaviour-driven development process to assist us to keep our quality in check.
Typical mature BDD process is made up of the following main activities:
" 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. "
1 Understanding the business goals.
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.
2 Defining and illustrating features.
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, like the following:
Features in this format are usually written by the BA in collaboration with the customers and development team. The feature will then go into the product backlog as documentation.
3 Working Backward and Understanding the Outputs
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.
4 Exploring and Mapping the Business Processes and Flows
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.
A simple flow for the submitting a leave application online feature might look like this:
Each activity in the flow invites discussion around variations, alternate flows, and extreme cases. For example, if we ask about the “check type of leave” activity, we might learn that the check is related to the type of employee and that there are different leaves associated, such as maternity leave and others.
5 Define feature with Gherkin language
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.
Teams often express acceptance criteria using the well-known “Given-When-Then” format, like in the following example:
Feature: Submitting a leave application form online
In order to save time and avoid paperwork, as an office worker
I want to be able to submit a leave application form online
Scenario: Employee with enough number of day’s leave
Given Jacob has 21 days for “Annual Leave”
When Jacob creates leave application with 5 days
Then The remaining of annual leave is 16 days
6 Automated Testing
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.
7 Deliver
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.
8 Completing the acceptance criteria
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.
9 Regression Tests
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.
