Why Software Bugs Will Always Exist (And Why We’ll Always Need Testers)

By | September 8, 2014

With all the advancements in software coding and automated testing tools, it would be natural to assume that software bugs are quickly becoming a thing of the past. However, widely publicized software blunders in recent years (e.g. healthcare.gov, Yahoo Mail, Heartbleed Bug) would suggest otherwise.

So how is it that in 2014, software is still so seemingly vulnerable to simple bugs and security flaws? Let’s take a look at some of the main reasons bugs are still around and examine why, whether we like it or not, they’re here to stay.

Image Source: Flickr User Guilherme Tavares

Software isn’t as Simple as it Used to Be

The reality of the situation is that while coding and testing tools have improved dramatically, they’re forced to play catch-up to software that is becoming increasingly more complex. Integrating platforms, building upon existing frameworks, and working with the remnants of legacy systems all contribute to an intricate collection of technologies that is all but impossible to handle without error.

Let’s take the tech factor out for a moment and use cooking as an analogy. Most of us can manage to follow a basic recipe for a simple meal like pancakes without much hassle. It’s a straightforward mix of flour, eggs, milk, sugar, and baking powder, and requires little kitchen expertise to make. However, following instructions on how to cook an entire Thanksgiving meal is a completely different story. There are dozens of ingredients involved and the chances of even a top chef making a few mistakes along the way are pretty high. The same goes for software. As more ingredients, tools, and techniques are added into the mix, it’s inevitable that more bugs crop up.

Recycled Code

I talked about the potential dangers of recycled code in a previous article, but it bears repeating. Open source libraries with major security flaws are widely available on the Internet and readily reused by some of the top app developers in the world. Pressure to meet demanding delivery dates, lack of expertise, and perhaps even a dash of laziness all contribute to the widespread proliferation of buggy code. Developers and testers both need to treat open source code more carefully, but this is an issue that will most likely persist for years to come.

To Err is Human

No matter how much progress we make in developing automated tools to identify bugs, behind every software initiative will always be a human. And as long as there remains a human element involved in software development, mistakes will be made. From the formation of an initial idea, to design, development, and testing, even the most careful project teams can encounter bugs related to miscommunication, logic errors, and coding slip ups.

Why We’ll Always Need Testers

Software testers, of the human variety, aren’t going anywhere anytime soon. Testing and coding tools are certainly getting better at detecting obvious bugs, but at the end of the day they are only tools. It takes a skilled software tester to design, write, and run automated tests. Furthermore, it’s important to remember that the absence of bugs does not equate to quality. A common misconception in the industry is that the sole purpose of a software tester is to identify defects. While that may be part of the job, testers also evaluate overall quality, usability, and user experience — a skill that can’t be automated.

Category: Quality assurance testing Web and software development

About Cheylene Thongkham

Cheylene Thongkham is a London-based technical writer and experienced software tester. She earned her bachelor’s degree in computer science from the University of Nevada Las Vegas in 2007 and an ISTQB certification in 2010. After working as a web application tester in the US, Cheylene assumed the role of Senior QA Analyst at a FTSE 250 company in London where she oversaw testing for mobile websites, business intelligence, and Oracle databases. She is currently working towards becoming an Oracle Certified Professional.