The idea of a new software release can often cause developers and engineers to let out an audible groan. Whether just entering the planning stage, preparing to test or readying for launch, software releases are time consuming, stressful and complicated.
More often than not professionals are left haunted by the question ‘Is it good enough?’ when preparing for release – a difficult question, as there’s no one objective answer.
It is this subjectivity that often trips developers and engineers up, leading to increased time spent re-testing and tweaking the created solution. This is what perpetuates the idea that a software release is something to be dreaded.
However, with the right practices in place during the process of software development, it can actually become streamlined, effective and – perhaps surprisingly for some – an enjoyable experience.
Enter: BDD – or ‘Behaviour Driven Development’
BDD is a form of agile methodology that can help to change software development from a chore into a proactive process. It is, effectively, a way of combining business interests and improved communications between departments (engineering, developers and managers, for example) with technical insight; this means that teams collaborate more effectively and are far more likely to create a product that meets the needs and requirements of a business with zero-known defects.
But how does BDD answer the question ‘Is it good enough?’
If people are unsure of what ‘good enough’ really means it can lead to compromise, and compromise is what causes defects to slip under the radar and become part of the final software release. We know that for most companies the idea of this is unacceptable – while the defects may only be low-level ones, any form of defect should be fixed as soon as it is recognised.
We took the time to break down what ‘good enough’ should mean to most software developers:
1. That it passes acceptance testing first time
2. That the team involved are universally happy with the quality of release
3. That the business – leaders and employees alike – are excited to use the software
4. That there are no known defects with the software
Utilising BDD throughout the process means everyone involved can be far more confident that a software release truly is ‘good enough’, that it genuinely meets the business requirements that acted as the catalyst for the solution’s creation, and ensures acceptance criteria have been determined and understood.
The first three points are fairly uncontentious and are probably pretty self-explanatory; but in order to answer these questions – and perhaps more crucially come up with the same answer across departments – communication and collaboration is required, and this is what BDD aims to provide.
BDD elevates the need for better communication within businesses – specifically between engineers/developers and other business sectors – whilst working in parallel with technical know-how. BDD is used by the software engineering team to discuss and engage with stakeholders to make sure everyone understands the business problems and agreed solutions. It sets the scene, meaning sponsors and stakeholders are more confident in what the end product will be and the production of a zero-known defect solution is made more likely.
Read our related blog: When is 'good enough' actually good enough? - How BDD can help achieve a zero-known defect release