Bug Busting: how to detect and avoid bugs sneaking their way into your system

A bug, as I’ve discussed before is the common term for a software defect. In simple terms, it’s where software does something you don’t want it to. There are a huge variety in the types of defects that can crop up and an almost infinite number of ways they can show themselves. Some will be glaringly obvious and stop a system even starting up, while others may be sneakier and only manifest under an incredibly unlikely set of circumstances.

* Did you know that on September 9^th 1947, a team of computer scientists at Harvard University were the first to literally “debug” a system. It turned out to be a real-life moth trapped in a screen!

You can categorise bugs in several ways depending on how you look at them; how serious they are, how likely they are to occur, how easy they are to fix, how much they impact a user, the types of testing needed to detect them, how they were introduced and so on.

A few software bug examples:

Performance issues:

These are errors that cause the software to run slower than expected or to consume more resources than necessary.

Crashes:

This is when a piece of software just stops responding or closes unexpectedly.

Integration errors:

These occur when a piece of software cannot receive data from, or send it to, other systems; think PayPal and eBay.

Execution Errors:

This is when a user cannot do what they need to; the software is not fit for purpose.

You may ask… how do these sneaky bugs manage to get into the software? If you understand how they get in, you can try and stop them! Prevention is better than a cure. Below I’ll share some of the cracks that bugs can slip into, but not necessarily the obvious ones.

1. Unclear expectations of software requirements

A defect is when a system does something a user doesn’t want. This doesn’t necessarily mean developers have made mistakes; they may have done exactly what they were asked to do. To make sure the software does what they want, we need to know exactly what a client is looking for through working with a Business Analyst to scope out expectations.

2. Impractical

One of the reasons a client works with  a software company is to benefit from expert advice; clients will request a certain outcome they are looking for, but we can supply advice on the best approach. What the client might want initially may prove to be far more expensive than they expected, may not work with their business needs or other systems or may be dependent on other things they’re unaware of. Compatibility and integration are major sources of defects, which can be helped enormously by choosing a sensible approach from the start.

3. Assumptions!

There are lots of people involved in the software development cycle; Account Managers, Business Analysts, Project Managers, Developers, Technical Consultants, Test Analysts, Clients, end users and more. While most of us communicate in teams using a common vocabulary, clients and end users can be from a huge range of industries and walks of life, and we don’t always use language in the same way. Jargon and abbreviations that might seem obvious to one group may be baffling or misleading to others. It’s crucial to make sure everyone is on the same page before getting started. Does APC mean Average Price Contract? Armoured Personnel Carrier? Adaptive Predictive Coding? Asynchronous Procedure Call? Are we dealing with millimetres, metres, inches or feet? (Ask NASA’s Mars Climate Orbiter why this one can cost up to $125 million…)

4. People take different routes and do unexpected things

It’s sometimes said the main faulty component of a system is the one using the keyboard and mouse… while this might be a bit unfair, if software is going to be used by a lot of people, some of them are going to do unexpected things. When planning the flows of a process, it’s important to consider what should happen when the user does something other than exactly what the client wants them to. It’s generally a good idea just not to accept input other than the correct ones, but you should always consider if there are alternative ways of doing the same thing and if your system should allow them.

Find out more about a day in the life of a Test Analyst at Software Solved, plus previous blogs covering the importance of software testing and the different types of testing.

Are you considering improving your system or have a new piece of software you are looking to have developed and tested? Get in contact with us today.

*https://education.nationalgeographic.org/resource/worlds-first-computer-bug/