Software failures

What We Can Learn From Software Failures

Software failures happen every day. You’ve probably experienced a software failure in the past week, or even days – fails as simple as an app glitching on your smart phone to serious ones like cancelled flights or crashing infrastructure systems. Software bugs have become so ubiquitous to everyone’s lives that it would be easy to simply roll our eyes and sigh, “here we go again…” – but if software professionals do that, we miss a valuable opportunity to learn.

A software failure is an invitation to explore. The fact that a bug is occurring means that there is something we can learn about our software, which will in turn, improve our future software. DZone and Tricentis recently partnered up to explore this very topic in a webinar titled “How You Could Stop Top Software Fails”, featuring panellists from a variety of backgrounds and perspectives: Tricentis’ Distinguished Evangelist Ingo Philipp, Senior Software Test Consultant and Trainer, Sue Atkins, Tricentis’ Director of Engineering, Michael Niessl, and Flood’s Performance Testing Consultant, Nicole van der Hoeven.

In the webinar, the panellists discussed the biggest software bugs they have encountered professionally, and more importantly, how to learn from them. As they observed, while each software bug likely has a complex history – how it got there, why it wasn’t discovered before it appeared in production, etc. – we can learn a lot by extrapolating the larger themes that connect all these software bugs together.

For example, how can developers keep up with the constantly increasing gap between software complexity and the speed at which the software is being developed? At the end of the day, that is one of development’s biggest challenges: supporting rapid innovation while maintaining a high level of quality. One of the ways to do that is through using Microservices – ie: releasing software in smaller and smaller packages, each of which have minimal impact on the functionality of the larger system. These tiny bits of software may have just one function, but they execute their one function really well and they can updated frequently with minimal risk.

Another question that should be addressed is, what do software testers need to change to keep pace with the ever-changing software world? One skill that is crucial for a tester is the ability to prove and demonstrate the relevance and value of their work. It is unfortunately quite common in an organisation for testing to simply be shoved to the side or undervalued. In those environments, testers need to stand up for themselves, highlighting their specialised skills and unique perspectives to demonstrate the value that they bring to their organisation.  Large, public software fails can be useful in that sense, because testers can use them as internal case studies to bring the topic of software testing back to the forefront of the organisation’s attention.

Studying software failures inevitably raises the question, “where is software and software testing headed?” One theory comes in the form of SDETs – Software Development Engineers in Test. Some even say that testing as we know it today will cease to exist and become “Optimising Engineering Productivity”. Is that actually realistic? As long as organisations agree that software quality has value, software testing will never go away. What will change, however, is how software testing is conducted.  The age of testing being a bookend to development, where testers manually follow step-by-step execution lists, is ending. The reality is that there is a need for testing in every stage of the development process. The idea that you can “bake quality in” to development with strategic testing is one of the practices that will be instrumental in stopping epic software failures and crashes in the future.

Want to hear more? List to the full webinar panel discussion on-demand here