In this blog we take a conclusive look at BDD and how it actively effects already existing tools and processes.
As discussed previously, we want all those involved in software releases to begin actively looking to fix outstanding defects as and when they crop up – never allowing the defect count to rise above what a team would consider a manageable amount. Naturally this requires engineering teams to switch their focus from developing and fixing, to delivery certainty.
But this, you may have guessed, requires a considerable overhaul of business perceptions; namely that reporting levels need to be altered so that only key metrics are flagged up, otherwise all those involved become buried under other pieces of information that do not inform zero known defect delivery certainty.
So, what changes are catalysed by BDD?
Some may be unhappy to hear this, but defect tracking tools become dispensable with BDD in place; this is because BDD scenarios are self-tracking. The scenarios – discussed and created between teams – are subject to technical insight and turn red if they fail, and green if they pass.
With the use of automation these scenarios are always updated, and as the teams involved become more familiar with how BDD works the need for a separate defect tracking tool becomes less apparent.
The way BDD scenarios work ensures that the number of defects slowly begins to reduce and gets closer and closer to zero, especially as the teams become more comfortable with how it works; essentially, defects are fixed on-the-go.
– do not fall into the trap of thinking that once the number of known defects reaches zero, there is no longer a need for BDD and continual testing. It is this mind-set that will lead to the number of defects escalating again.
We like to be proactive about everything we do – and that is exactly what BDD and testing should be: testers should proactively use the practice to work with business analysts and developers to ensure that defects never make it past the development stage. Not only will this make for a more effective testing and development stage, but it also saves costs as fixing defects early on is much cheaper than trying to fix issues discovered through reactive testing at later stages.
So, what does successful BDD look like?
Given that the basic principal of BDD is a combination of increased communication between team members to form scenarios that can be leveraged to create zero-known defect software releases, success can be defined by implicit and explicit trust between stakeholders and sponsors in the engineering team. Those at the top should believe that the engineering team is capable of delivering the specified metrics.
We’ve noticed that with BDD, confidence from sponsors in the software release team’s ability increases – and as a direct result the volume and frequency of metrics requested tends to reduce. This makes BDD a self-perpetuating cycle, whereby it makes zero-known defect software releases easier during the development and testing stages, plus continues to decrease the number of metrics that require attention.
Let’s wrap this up
BDD gives quality and quantity for valuable deliverables. It is a practice that helps to answer the question of when software releases are ‘good enough’ and can help teams achieve the end goal of a zero-known defect release. It helps with time and budgetary constraints by ensuring software development teams and all those involved reap the benefits of a highly efficient system.
If you couldn’t tell, we’re fans of BDD. It helps businesses be proactive about software releases and reduces the panic some professionals feel when release day comes around. Here’s a final quick round-up of key success criteria for successful BDD implementation:
Read our related blog: What is 'good enough' when it comes to software releases? - An eye on BDD
- Stakeholders and sponsors must be involved at every stage
- Scenarios should be well defined, but not overly complicated
- The idea of a zero-known defect should be accepted by the team as a whole, and a goal they are all happy to reach for
- Continuous integration with the help of automation should be used to provide real-time feedback to development and engineering teams
- Executing scenarios should be used as the regression test suite