Testing 101 – why you need to start testing your app, yesterday

Think about your typical 2-packs-a-day smoker. It’s hard getting them to acknowledge that each of those cigarettes contributes to lung cancer, because “those things only happen to other people”. With software products, each piece of new code is prone to add future complications. And still, the teams think 

nah… a serious bug in production would never happen to me! At least… not one that would matter.

Facing the risks

In 1964, the NASA Mariner 1 was USA’s first attempt at sending a spacecraft to Venus. Little after the launch, a software bug in the navigation system caused the shuttle to go slightly off-course, forcing NASA to activate the self-destruct process. 18 million dollars blew up that day, literally. And why? A missing hyphen in the software code.

In 2016, the Amazon site was unavailable for 20 minutes, but the losses of the company in terms of sales were 3,75 million dollars. According to a 2002 study, about 59.5 billion dollars are lost from the US economy due to software bugs. And what is even more surprising, a third of these losses could be avoided by improving the quality of the testing processes.

So yes, it will happen. Yes, it will cost you. Yes, you can avoid the loss. But the testing phase of a software project is often treated with a degree of superficiality.  You will hear people procrastinating tests or even dreading them. But why? And what even is testing?

Glitches get stitches

The official definition is this: an investigation conducted to provide stakeholders with information about the quality of the software under test. Did you get that? I thought so. Wikipedia is rarely any help in understanding something, is it? So I’ll try to explain it better. Testing is any interaction with a piece of software where we observe the result and appreciate its meaning. This meaning can be anything: business value, computational correctness, pleasant user experience, speed or resilience to multiple interactions. The point is we set some expectations, we interact with a software application or service and then we quantify whether our expectations have been met.

But usually, when we talk about testing, we refer to hunting for bugs. So your basic testing will be carried out by someone stressing the system using different interaction techniques. A good tester will test for the most basic cases, but will also try to break the application using erroneous input. Testers spend a lot of time and effort into reproducing any scenario that might cause money loss, data loss or customer dis-satisfaction. With one key difference: they usually perform these in a sandbox environment where nothing really really bad can happen.

Testing is not easy, because, as you probably know or imagine, Murphy’s Law is a big part of it. The system can be tested in development multiple times with the most impressive variety of cases, but still break in production because of a minor, unexpected issue that slipped through the cracks. This is one of the excuses that product owners often cite for not rigorously testing software: what’s the point, if there is still a chance that the application fails? Well, to answer that, I have to use the world’s favourite risk management analogy of all times: the seatbelt. While you can still die, even if you are wearing a seatbelt, it is probably not wise not to fasten it. Testing, like wearing seatbelts, statistically reduces your risk.

Ok, but how can I start testing my application?

Glad you asked. Well, first you have your basic manual testing. The simplest way to test is just getting someone in front of a computer or mobile screen. Now have them interact with the software. That’s it. A trained tester will know how to do all those tricks to break the application and report the issues back to a development team.

But, going forward, this gets pretty cumbersome, pretty quick. Will that tester keep repeating the same checks each and every time something changes? What if it’s a huge app, with many features and dependencies? How can testing teams even keep up with the development speed and stay sane? Well, don’t you fret, sometimes you can use software to test software, in what is called automated testing.

With automated testing, we abstract some of the repeated interactions with the tested software. Then guess what? We use other software to automatically perform these basic actions time and time again. Manual testing will still play a big part, but we automate most of the mundane tasks. The main drawback with automated software is that you need specialists that can automate these tests, a task which, in addition to know-how, requires time and effort to implement. Of course, it’s worth it in the long run, but can be more trouble than it’s worth if the tested app changes a lot.

But it’s hard!

We know software testing is not your favourite activity. But don’t panic yet. If you decide to take software Quality Assurance seriously, you are in the right place, because we can help you. We are preparing a series of articles  to guide you through the process and help you learn more about software testing. For a sneak peek, let’s say we’ll talk some more about how testers “break” apps, benefits and drawbacks of automation, guides to hiring remote QA teams and so on.

If you are in a hurry, there is no need to wait. We also offer testing and quality assurance services to our customers, so contact us directly and we’ll show you some pretty cool stuff we have up our sleeves.

Yes, we know it’s hard. That’s why we’re here to help. Instead of thinking you are not testing well enough, please think quite the opposite. You are steps away from a good night’s sleep, not worrying about software failures.