91������

“Bug” is a common word among software professionals. Also known as defects, a bug simply means the software isn’t behaving as expected. The word bug is used quite liberally to refer to both the symptom and the cause. 

In proper terms, a bug is really a human error that produces a defect that causes a fault in the operation of the software, resulting in a malfunction that causes some sort of damage. Unfortunately, most software defects cause damages that are far worse: loss of time and nerve.

Sometimes, the same sequence of actions can result in a malfunction for one user but not the other. Software folks often call these “random bugs”. In reality, there are no random bugs. The effect (the occurrence of the fault) may be random, but the cause (the error in the code) is always there: the malfunction is happening for a reason.

To Err Is Human

The cause of a programming error is usually one of the three “misses”:

Mistakes Lead to Massive Malfunctions

Developers often face unrealistic deadlines to deliver new functionality, make enhancements or deploy fixes. Under these conditions, it’s easy to imagine how software developers make mistakes. They hit the wrong letter, confuse one variable with another, accidentally use “greater than” instead of “less than” or place an index value off by one. A tiny typing error may, indeed, be the root cause of a massive malfunction.

Misunderstanding Is a More Complex Form of Human Error

The developer makes the code behave exactly as they wanted; with no mistakes. Instead, the developer misunderstands how the software should behave. We have all done it: read instructions, believe you do exactly as instructed, just to realize later that you misunderstood the instruction.

Software developers’ instructions are known as “requirements”. Requirements are plain English descriptions of how the software should behave. Such misunderstandings tend to get expensive. They are typically found in the later testing stages and testers often fail to spot them, too.

Oftentimes, the error is surprisingly in the requirement itself. It is not uncommon for a developer to implement a requirement exactly as it was described and find out later that the software does not behave as the real users would have expected. This is still an error but not a programming error.

Misassumption Is the Most Challenging Form of Error

As Einstein would say, “Assumptions are made and most assumptions are wrong.” But software developers need to make plenty of assumptions.

They assume that their programming tools and underlying operating systems are free of errors. They assume the utility libraries they use behave in a certain way. They assume the other system their code is interfacing with always responds appropriately. They assume the response from that other system is never longer than 1024 bytes. And so on. You can never be prepared for everything.

Those dependencies do not, however, remain constant. The underlying operating system gets a version update or the developer next door releases a new version of their library. The URL of the web API changes. The beauty of misassumptions is that a developer’s correct code may begin malfunctioning even though the developer did not touch it at all.

The Criticality of Finding Bugs

A software tester's job is to find the bugs in a controlled environment before the software is deployed to real users. And with strict timelines, there’s never enough time to test thoroughly. Besides that, testers are human beings, too, and may make errors. At best, manual testing can reduce the probability of malfunction in production but never fully eliminate all the bugs.

If testers don’t find many bugs, it may mean several things:

• the software was poorly tested: the bugs are there, but we just don’t know it yet
• the developers have done a great job testing their code so that there’s little left for the tester to find
• customers will find the bugs and then complain

The golden rule is to never confuse the absence of proofs with the proof of absence. Just because you didn’t find a bug does not fully disprove that a bug can exist. With such uncertainty, how can you optimize the testing process to maximize the number of bugs you find?

To start, you need to remove as much human error as possible. That’s where test automation comes in. Combined with continuous delivery, automated testing will enable your team to test more thoroughly and earlier in the process. Test automation enables you to catch bugs at the source rather than later down the pipeline when it’s more difficult and more costly to correct.

With pressure to deliver every functionality faster, time is of the essence for developers, which, unfortunately, is a scarce resource they never seem to have enough of. Leveraging test automation alongside your developer workflows will boost productivity without the worry of introducing more or missing bugs early in the dev process.

If you’re looking to provide some sanity to your dev team and want to empower them with a DevOps solution that improves speed and quality, visit copado.com/robotic-testing for a demo.

About the Author

Esko Hannula is an experienced software executive with a life-long interest in the connection between software quality and business performance. He’s known for insightful and often provocative ideas. Prior to joining 91������, Esko has collected 30+ years of leadership experience in software, IT, telecom, and services industries.