Apps Break Where You Least Expect Them To

Software complexity is eating the world

The largest critical bug I personally saw at TestTheTest was when one of our clients broke their user signups. For a B2C startup this is as serious as issues can get: startups spend a huge amount of hard-earned (hard-invested) cash to get signups. So when potential users arrive at the site only to find that it doesn’t work — those people are not likely to ever come back. Money (not) well spent.

Moving fast and breaking things is just the way to go at tech startups, and so we can have an idea about where the balance will fall from the tech product manager’s “fast, good and cheap” Iron Triangle. In startup land, we’ll definitely see more unicorns than bug-free apps.

Every piece of software has bugs. They happen for many reasons, such as:

• Changes in requirements – because features will come and go
• Changes in the ecosystem – because Apple and Google will always introduce new devices, new browsers, and new everything
• Rescheduling resources – because people in your team will leave at the exact wrong time
• Redoing work – because we needed to rush it the last time and nobody understands how it works now
• Too much code – because we didn’t have time to find a package or framework – or didn’t care to look
• It’s in someone else’s code – because everyone, always, uses 3rd party packages, and we can’t test each and every update, all the time

This also means that regression testing, regular QA and allocating time for fixing bugs is a critical – and ongoing – process. And to make that process as efficient as possible, having a good idea of where bugs are most likely to occur in your app can be hugely beneficial.

Bugs… They’re Everywhere!

Bugs can pop up in literally every feature, even the ones that people use often. And they can pop up anytime – Murphy’s law dictates that the bad code will go into production right after the marketing team has blown most of their budget on attracting new customers.

However, there’s one area of an app that testers often think is ‘safe’ and will skip first when they run out of time – despite it being a hugely popular bug hideout. That place? The oldest, most trusted, established features.

There are two reasons for this:

1. Lack of visibility

Think about the most visible part of your app. It’s the new features, right? During active development, your app’s latest offerings will be seen by your developers, your testers, your project managers, and anyone else keen to check out what the latest features can do.There’s excellent oversight from all directions.

There’s practically zero chance that a bug is hiding out in your new features undetected. It’s much more likely to choose the quiet, cobweb-ridden corner of your old features; that place where no one ever thinks to look. Visibility matters when it comes to bugs.

2. Chain of Effect

In all software and always, functions depend on each other. When a developer works on a new feature, they often rely on functions previously written by themselves or by others. There isn’t always enough time to understand exactly how the old function’s internals work, let alone re-architect the code to be more reusable — so when someone changes the old functions for the new feature… well, most of the time nothing bad happens. But sometimes, bugs start showing up.

Everything that developers do – adding a new feature, removing an existing feature, re-designing the UI interface, integrating modules, managing the database – it all has a ripple effect right through the app.

New work can hugely affect old work, either directly, or indirectly by increasing the complexity of the software and the system as a whole. And yet testers rarely take the time to go back and retest everything. They just don’t have the time, or simply don’t think to, because “that feature has always worked and we haven’t changed anything there”.

Common bugs to look out for

The secret to keeping on top of things and finding bugs quickly is to get into the habit of not only testing regularly but testing everywhere. Some common things to test include:

• Connection and speed
• Backend functionality
• How the app handles interruptions (e.g. a phone call)
• Permission issues
• Page layouts and screen sizes

However, even the best QA tester can miss bugs in smoke tests. That’s why it’s considered best practice to create testing checklists that QAs can tick off every time they perform their regression tests. Exactly what will be tested will depend on the nature of your app – but don’t skip something, just because something is annoying to test and retest, over and over again.