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 smartphone to serious ones like canceled 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 panelists 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 has 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 be 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 organization for testing to simply be shoved to the side or undervalued. In those environments, testers need to stand up for themselves, highlighting their specialized skills and unique perspectives to demonstrate the value that they bring to their organization. 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 organization'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 organizations 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.