Do I really need to test my code?

Dad Joke: What kind of plant goes into the bathroom? Toilet-trees!

Photo by ThisisEngineering RAEng on Unsplash

For many people, testing is fun. For some other people, however, for obvious reasons, testing is no fun at all. Testing is an important phase in the software development lifecycle. A system is tested for performance, scalability, functionality and usability. By testing software, we check for correctness and find out if there are any defects or bugs.

What is a software bug?

Let’s talk about what a bug is. By the way, I want to believe that you’re not thinking about insects. A software bug is simply an error or fault that causes written code or program to produce an incorrect, invalid or undesired output.

This may sound quite trivial, but it actually is a big deal. When proper testing is not done, it could lead to loss of life and property. Some disasters have actually happened in the past because there were bugs in a system. We’re gonna talk about some of them in a bit.

Unsettling situations in history as a result of software bugs

In 1985, the Therac-25 — a machine built to deliver radiation therapy to cancer patients, malfunctioned as a result of race conditions in the codebase, and lack of safety features, killing three people and injuring three more.

Race conditions happen when your code tries to perform two or more processes at the same time, but due to the unpredictable order that the processes might occur, it could lead to unexpected or undesired behaviour.

Another situation happened in April 1999, when a software bug caused the failure of a $1.2 billion military satellite launch, and this was the costliest unmanned accident in history.

The third scenario happened in May 1996 when 823 customers of a major US bank were credited with $920 million. Now I’m pretty sure some people do not consider this a bug.

So we see the importance of testing a system even though in reality, with testing, we cannot always identify every single possible failure within a software. However, we can assume some hypotheses and determine the correctness to a certain degree.

Different types of bugs

There are quite a number of bug types, but I’d be identifying five:

1. Security bug
   This happens as a result of how the code is written. Your app could therefore become vulnerable to an attacker who can easily find a loophole to gain unauthorised access or privileges to your software. For example, when you don’t properly sanitize user input, an attacker can input malicious script into your application and gain access to your database.
2. Functional bug
   This has to do with the functionality of the application. Examples include when a user searches for an item and the app crashes, or if they click on the login button, but it does not log them in, or they add items to the cart, but the cart does not get updated. These are all functionality bugs because it’s expected that the app should do those things at phase value.
3. Performance bug
   This mostly has to do with the speed, stability and response time of the software application. For example, a page taking ages to load, or a button click that just keeps loading typically leads your users to be dissatisfied, and more often than not, abandoning your site. I wrote a bit about this here.
4. Error handling
   This is quite common, and new developers most especially create this. For every piece of code involving user input, there needs to be a way to communicate to the user when there is an error. For instance, if they’ve visited an invalid page, they should see a 404 NOT FOUND page. If they’ve entered a five-character password, instead of an eight-character password, they should see validation error messages. In essence, if the app is not properly handling eros, then that’s a defect.
5. Regression bug
   This is probably the most frustrating type of bug, the reason being sometimes it’s quite tricky finding out why it happened, especially if you work with a large team. Imagine the A.C in your car getting bad, and you take it to the mechanic. The mechanic fixed the A.C, but halfway into your trip, you try to turn on your radio, and it doesn’t work, but you’re certain it was working before. Regression errors happen when a feature that worked before just stopped working due to certain events such as a system or dependency upgrade or new functionality added to the codebase, or even a time zone change as a result of daylight savings.

Those are the common types of bugs found in typical applications, which one should take note of. How do we handle them to ensure they do not degrade the quality of the software? We test our code to catch errors as much as we can, and this brings us to the different levels of testing. But before that, let’s talk about things to look out for when testing.

Photo by Randy Fath on Unsplash

Things to look out for when testing

• Functionality — Before thinking about edge cases, you need to check for functionality. Does the program do what it is required to do? When I click on a submit button, does it submit information or do nothing? We’re checking if the requirements are met.
• Performance — Does the software written perform within a reasonable period of time? If it doesn’t, it might be worth looking into things like expensive database quieries or optimizing time-consuming algorithms.
• Scalability — When testing, you also want to make sure that your solution is scalable, meaning it is optimised for a large set of data or requests.
• Usability — Also, you’re looking out for the usability of the product — how users can easily interact with your software.

Levels of testing

1. Unit testing
   A unit is simply the smallest testable component of your application. It is the most basic type of testing, and it involves you isolating each part of your code, and testing components to determine if it behaves as it should. With this, you get to see a more granular view of your application, and it is usually written as the developer’s work on the codebase. A typical example of unit testing is checking that a user enters the correct email format in the input field.
2. Integration testing
   This has to do with testing how a component or module works when combined with another component or module. It could be verifying correct data flow from one component to the other, or that the database is successfully queried from a module. The main goal of this is not to test the modules or components themselves, but the connection or interface between them.
3. System testing
   Here, the system as a whole. Basically, the whole system is tested as one single piece to ensure that it meets specifications and confirms that it meets quality standards as well. This test is typically carried out in an environment that mirrors the production environment, so this gives you a peek at how the app will perform when released.
4. Acceptance testing
   Here, the product is determined if fit for release or not. It is usually performed by the QA team — they would have a set of pre-written scenarios and test cases to test the application. A common test — UAT (user acceptance testing) is also done at this stage by asking users to check for functionality and validates that all the requirements are met.

There’s an interesting question that comes up often — if software engineers have to write test cases, why then do we require software testers or a QA team. Why not just have testers do the whole testing bit while engineers write the code?

Here’s my personal opinion — when engineers test their code, not only does it help identify arrears to refactor in the codebase, but it is also useful in filtering out errors from the codebase before it goes out for additional testing. By doing this, you prevent a bottleneck situation where the QA team finds a really tiny error, then takes it back to the development team, and then the development team fixes it and probably misses out something, and the back and forth seems to never end. Also, I think that the perspective of a developer building software is significantly different from that of a tester. While a developer is primarily looking to implement a technical solution, build a feature, fix a bug or optimize the software performance, the tester is literally just looking out for bugs — not necessarily what works, but what does not. I, therefore, believe there’s still a huge need for this level of scrutiny in building any functional product.

With this, I hope you have a more critical approach to your code by testing it to avoid problems in the future.