Accessability Links

When is ‘good enough’ actually good enough? – How BDD can help achieve a zero-known defect release

In our previous article we discussed how developing software for release that is deemed ‘good enough’ by everyone involved, is easier said than done. BDD can reduce the likelihood of defects, but can’t eliminate them completely.

The release of zero-defect software in today’s working world is pretty much impossible, what with the complexity of modern software and integration between numerous different components. If a company is aiming for a zero-defect release, stakeholders and engineers alike will be left downtrodden when it (inevitably) doesn’t go to plan.

But, a zero-known defect software release is entirely achievable – and is pretty self-explanatory. A zero-known defect release means that those involved have managed to define and test all scenarios related to the software and have ensured it passes without issue.

Ultimately, a zero-known defect release means that the scenarios tested have been signed-off by business leaders as being truly representative of the business needs that influenced the initial software development; so how are scenarios developed?

Enter BDD – again!

BDD lends itself perfectly to the development of scenarios when it comes to testing for zero-known defects, as it combines the technical know-how of the software engineering team (which includes business analysts, testers and developers) with stakeholders, who can clearly communicate the problems that require addressing. It is the use of BDD that helps to set the scene for the engineering team, leading to a more robust zero-known defect release.

But how can those involved in a software release ensure it is ‘good enough’ from the off? Professionals need to ensure that the solutions pass acceptance first time – this requires confidence in the development stage, which must utilise manual regression testing.

The role of manual regression testing

This is a form of testing that highlights any software issues that may have gone unnoticed in the scenario development stage. These may have come about as changes are made to the software so it meets business goals more entirely.

Whilst manual regression testing is therefore important, it can be time consuming and it is unable to provide adequate assurance at the beginning of the acceptance phase, bar for a limited number of delivered features.

So what’s the conclusion?

Manual, therefore, is not necessarily ‘good enough’; although it may have a role to play, automation is perhaps a more effective method of providing continuous, real-time assurance that software is meeting business goals. Our next article will explore the use of BDD alongside automation to provide continual assurance.

Read our related blog: When is 'good enough' actually good enough? Automation to the rescue - Continuous BDD assurance
Add new comment

Meet the team

Back to Top