Dmitriy N. Full-Stack Developer

How bugs in apps appear and why you shouldn't be afraid of them

What is a bug?

At its core, a mobile app is a code. A bug is a mistake in the code. It causes the app to behave incorrectly, such as freezing, crashing, or not responding to user actions.

Incorrect behavior is a natural response to a bug. Imagine that you have written a complex instruction with a lot of steps, and in step #404 it is unclear what to do. Because of this, the person who will follow the instruction will never come to the right result. It's the same way with the app. It will not understand how to behave if there is an error in its "instruction."

Well, isn't it possible to write a code without errors right away?

This is only possible in an ideal world. And in ours, it's not. An application is a complex system. With each new element, the interaction of its parts becomes more complex, and this leads to errors in the mobile app. It's like communication: the more people there are, the harder it is to agree. The developer "connects" the different elements into a single code. If the element is unknown (a third-party library or a server not yet worked on the project), the developer can't foresee if the element will find a "common language" with the existing parts of the code.

In addition, errors can appear because of trivial "typos" in the code of a mobile application. Writing code can be compared to typing a message. We do it every day and still make mistakes. We reread the text ten times and only notice the misprint when we have sent a message to the person we are talking to. Neither spell checker nor T9 guards against this. We are all human and we cannot be concentrated 24/7.

So, a developer may fail to notice his mistake. Note that there are usually about 150 thousand strings in the code of a mobile application and it is impossible to keep track of all the characters.

Are the developers the reason for errors then?

No, they aren't. Errors in an application can also occur on the side of the integrator, a third-party service the application "cooperates" with. The developers cannot prevent it because it is beyond their control.

For example, no ecom-app does without integration with the payment gateway - the bank page where the users enter their bank card number for payment. For the user, the transition from the app to the payment page is not noticeable: Apple, Google, Samsung Pay are also payment gateways, but try to convince the person that the payment is not in the app. Focusing on the bank's response, the app will tell the user: "Congratulations! The purchase is complete" or "Oops, something went wrong." If something went wrong, that means the problem is on the integrator's side. The only thing mobile developers can do in this case is to "knock" to the gateway tech support department and warn them about the failure.

The appearance of errors is a natural and logical process in application development. And the developers are ready for it. They are responsible for their own bugs: not only do they know that there will be errors, but they also know how to look for them. To do this, the developer writes autotests - parts of the code that simulate the interaction between the user and the application. The developers check the written code with the help of autotests, fixes the obvious errors and continues working.

So if the developer checks everything, why are we even talking about it?

Autotests are not enough to fully check. They only cover the formal working algorithm, but cannot reproduce the behavior and motivation of a "live" user. Only humans can do that. That is why verification of user cases is the task of another specialist in the team - the QA-engineer, or tester.

When testing an application, the tester is in the role of the user: he opens the application and performs the same steps that the person who installed the application is supposed to perform.

The tester goes through a specific user scenario. This should be done on different devices with different OS versions and different screen sizes to make sure the app will behave correctly on all models. If something does not work or does not work correctly, the tester fixes the bug and sends the build for fixing (reworking) so that the developer can fix it.

Great! The tester has found all the bugs, the developer fixed them - you can relax.

Wait, it's not that simple. You need to be prepared for bugs to be found not only during development, but also after release, when the app appears in the app store, such as the App Store or Google Play.

This happens because we cannot cover all user scenarios, no matter how hard we try. There are a lot of mobile devices and a lot more the actions a person takes in an app. The number of smartphones multiplied by the number of actions gives infinite room for error. And there is no hero who can break down all of these cases. So it's better to prepare yourself in advance for the bugs that will occur in a mobile app, and let the development studio fix them.

And how might the bug affect the operation of the application?

It depends on how serious the bug is. Conventionally, bugs in an application can be divided into three types: critical, significant, and unimportant.

Critical bugs prevent a person from using an application. They block the main function of the application and prevent it from working for the customer's business goal. Significant bugs are not dangerous to the business goal, but they can inconvenience the person in using the application. And non-significant bugs are minor irregularities that the user can't notice. This is what it looks like on the example of an app-store:

If the "Pay" button doesn't work, it's a critical bug: it prevents the app from selling, from performing the function for which the app was developed.

If the "Pay" button is not in the center, as it should be, but on the left and its edge protrudes ugly beyond the screen, but the user can still click on it - this is a significant bug.

If the button "Pay" on the order screen is gray rather than black as the designers intended - this is an insignificant bug.

What should I do if there is an error in my application?

First of all, stay calm, because there is no bug that can't be fixed. If an application is released with a critical bug, the development studio takes responsibility. This means that as soon as the bug is detected, they will fix it. But with an unimportant bug, the app can live, so the studio will postpone fixing it to the next scheduled release.

Okay, so the critical bug gets fixed first?

Not really. To know which bug of an application to remove first, you have to determine not only the severity of the bug, but also its priority: medium low or high.

A critical bug will not always have a high priority. Let's imagine that a user can't add pants to cart, because the "Add to cart" button for this product category is broken. If the user can't add pants to the cart, it means he can't buy them. This is a critical bug that needs to be fixed. But at the same time, there's another problem on the app's home screen - the name of the store is misspelled. This is a significant bug, but it has a higher priority. We'll explain why in a moment.

Not everyone needs to buy pants right now, so not all users will get to this product category. Yes, the bug will reduce sales, but it will not kill them completely. So, the developers will have a time buffer to solve this problem. But a typo in the brand name on the main screen will be noticed by everyone. This is a big blow to the company's image. It will affect the attitudes of customers toward the store and discourage many from using the app. As a result, conversion in the application will fall.

So I don't have to be afraid of bugs?

Exactly. To a developer, bugs come as a given. We expect them and know how to fix them. And we tell our customers about it. Sometimes they can act as testers, too - we give them the finished build before release, so they can make sure the application is okay.

What if I outsource the application to another team for support?

Fixing bugs that don't belong to us is more difficult. The point is that the longer developers have been working on a particular project, the more immersed they are in its context and the faster they will orient themselves if they find a bug. New developers will have to learn everything from scratch. But an experienced team with established communication and workflows can quickly understand a new project.