What is the difference in mobile and web app testing


The web/mobile division isn’t just for developers. Testers, as a rule, also like to work with something one. And if you are just embarking on this path and do not know what to choose and what is the difference, then this article will help you.

We asked two experienced professionals about how they got into testing, how mobile and web applications work differently, and what juicy and non-trivial tasks may appear in the process of work.


How I got into testing

There were two reasons for this. Firstly, I like to learn everything new, and the digital sphere is a challenge for me, since initially I have a liberal arts education. Secondly, I was always surprised by the failures in the application. At such moments I thought: “How did they miss this?” As experience has shown – it is very real.

Tasks for a mobile app tester

If expressed in a non-IT language, testing of mobile applications is checking an application for operability, parsing documentation, and thinking through unusual and at the same time everyday situations where the application may operate incorrectly.

Why I like testing mobile apps

I work with an application that will be used by other people, and not by a couple of people from my environment, but by many thousands. This is an unusual feeling when you are testing an application that everyone is talking about and being the first to know new features and capabilities. And it turns out that the tester is the last link before the release of the application. It is he who conducts the final testing and gives the go-ahead for uploading it to the App Store and Google Play.

Testing of mobile applications is very much tied to the features of the device. After all, modern smartphones have the widest functionality. And it is when working with them that you encounter challenging tasks, and checking an ordinary chip turns into a little adventure. Here are some examples.

A customer needed to implement the ability to send messages to his customers’ smartphones at the moment when they were close to the doors of their store. It was fun to test it: a circuit from a smartphone, a speaker and a low-frequency transmitter, a trip around the office, checking the functionality in a meter, two and five from the device, working through the wall, and so on.

And once I had to go to the customer’s store to check the application. Initially, the problem was like this: the barcode for bonuses was updated every 7 minutes. But if the user opened the application (for example, at the beginning of the checkout line) and did not touch the phone for 7 minutes, then the barcode was updated in the database, but not on the phone screen. And it turned out that when the buyer approached the checkout, his barcode stopped working. As a result, the bug was fixed, and I needed to check it. It was tested this way: I went to the store with a test iPhone with the screen on (it was strictly forbidden to touch the screen), was walking for seven minutes waiting for the barcode to be updated in the application, and only then went to the checkout. I will remember the reaction of the guards and other visitors forever.

The other day, we needed to club our application with the Google Fit app so that the user would receive additional bonuses for steps. Guess how it was tested? 🙂 These are just some of the examples. It is impossible to imagine such non-trivial and fun tasks in web testing!

Challenges of mobile app testing

Smartphones and tablets are complex devices. With each update, the software and hardware functionality expands. Very often they use additional devices: headphones, SIM cards, bluetooth devices, styluses, external batteries, and so on. You need to take such moments into account when testing. We have to answer questions like how the application will behave if the phone is connected to a cable, or if it is used without a SIM card, and more. And these “ifs” must be constantly taken into account.

Do not forget that managing smartphones is much more difficult. These are swipes, gestures, tilts, network level, navigation, voice control.

When testing web applications and sites, everything is carried out within the monitor of a desktop computer or laptop. And only sometimes a smartphone or a tablet are used. But when testing mobile applications, the workplace looks like this: a computer, several devices, and cable spaghetti. Sometimes there is no space for a cup of tea.

It also seems that now only two operating systems are used when creating mobile applications: iOS and Android but there are many current versions and sub-versions for them. And for Android, each manufacturer has each own shim. It is significantly harder to find bugs and to test these combinations.

Here is an example. Xiaomi smartphones are very popular right now. Most models use the signature MIUI shim. Before the release, the application is tested, but it is impossible to foresee all the options. Somehow, after the release, a huge bug surfaced: when you click on a certain button in the application, its work crashed. It turned out that this bug was only on the Xiaomi Redmi Note 5A Prime device, which uses the 10.2.1 shim! Everything worked on 10.2.0, 10.2.2 and others. For this test, I even had to connect the smartphones of my loved ones.

A tester in a mobile development department has more responsibility than a web development department. Correcting the “mistake” in the latter is a matter of a couple of minutes. On a mobile app, this will certainly take a couple of days cause after making changes, you must definitely check everything again, and then wait a few days for the corrected app to appear in stores.


Why, after all, do I like testing mobile applications? Because I like everything new: new devices, new functionality that makes it possible to implement juicy applications. Even with a standard project, you may run into snoop and bold features that are fascinating to work with.


How I got into testing

By education, I am a true IT specialist, and I graduated from the technical department of the university back in 2010. But I went to work not quite in my specialty: the life curve led me to a sphere far from development – advertising and media. As a result, already in my fourth decade, I finally realized: “More than anything in life, I want to return to the roots. I want to work in IT. I see myself only there and I will do everything to return there.”

For many years, everything I studied at the university was forgotten. And how to enter IT again and from scratch? On the Internet they write that the fastest and easiest way is through testing. Well, through testing it is. I counted my savings, determined an acceptable period for training, quit my job, bought training courses for a tester and started studying.

Tasks for a mobile app tester

In short, people now interact with the Internet in two main ways: through mobile applications and browsers. Colleagues from the mobile division are engaged in just iOS and Android, and we are in chrome, firefox and stuff the like this. Our task is to verify that the product works correctly in all browsers declared by the customer and in the required resolution range.

Why I like testing mobile apps

I love when everything works the way it should. You probably do too. For insance, you go to some educational site. It is very useful, there is a lot of information you need, but for some reason the video tutorials do not work – there is no Play button. And your friend is doing well with the same task.

As a result, you are reluctant to install an additional browser for yourself just for the sake of watching video courses on this exact site. And later, having decided to watch the lesson from a mobile phone in the subway, you find out that video lessons do not work in the mobile version either. It’s embarrassing and annoying, right?

Now imagine that you personally can influence the quality and performance of such products. To make sure that they work always and everywhere, bring joy and benefit to people. And you get paid well for it. Cool? Cool!

For me, web testing is easier and more exciting at the same time. We do not face the main pain of a mobile tester: a large fleet of devices and operating systems, especially for Android.

Challenges of mobile app testing

I will demonstrate it with one simple example. Let’s say you were hired as a tester for a project. What is the project and how exactly should it work? You need to know.

Any team uses certain tools in their work, with the set specially determined by the specifics of the project or team members’ habits. In our case, the project requirements are stored in the Confluence system. You need to master it and study the documentation.

Now you know that you are making a website that should show the current number of gray hares in the forest. You access this site from some browser, but the number of hares is not displayed. It would seem that this is a bug. You just need to show it to the developers, and they will fix everything. But you find out that bugs need to be introduced, for example, in the Jira program according to certain rules. Now we need to study this tool and the standards for bug reporting. So, you learned that the team considers not just pointing out a bug as a sign of good manners but also its localization with confirmations.

You find out that our site makes a request for the number of hares to the server, and the server returns a response. So, we need to find out which side the problem is on. This is where the skill of working with the browser-based developer console and understanding the server response codes will come in handy.

It turns out that when requested, the server returns an error 500. The problem is localized. A screenshot of the server response from the console is attached to the bug as confirmation. So far so good.

Later, a message came from Jira that the bug was fixed. So, you need to double-check it. You go to the site and see that there are 42 gray hares in the forest. Is everything working as it should? Right? Better check it. The documentation describes the logic of the server. It turns out that the number of hares is daily uploaded to our database from the general database of all forest animals.

Let’s check our database. This will require access to the database and the skill of writing queries in some SQL-like language. In the database you see records about hares and, in particular, their colors. By running a request to count all hares, you get the number 42. But our site should only count gray hares. By running another query, taking into account the color, you will find out that there are actually only 10 gray hares. A new bug with an attached screenshot of the query results goes to the developers.

Finally, your site shows the number of gray hares. It would seem that now everything is exactly working as it should. But let’s check one more thing – the relevance of the hares’ number. Hares come from other forests and go to other forests every day. The documentation says that our database is updated every day and loads data from another shared database. You have to look into it too. If there are also 10 gray hares in it, then everything should be fine.

Fortunately, the data match, and for greater certainty, we will look at the number of gray hares for the past days and see that it has changed every day, and the number 10 is gray hares for today. You might be able to check the validity of the data in a more graceful way. For example, by checking the corresponding fields in the database with dates that correspond to the date and time of the last update.

All the checks described above should not be forgotten and lost. And their results should be clearly displayed somewhere. There are also special tools for this. For example, Allure is a program for managing test documentation. Using it, you can write your own tests, form plans from them and run test sets. If necessary, you can update the tests, remove outdated and add new ones. This way you will be sure that testing controls ever aspect and does not miss a thing.

Over time, you will want to simplify the routine and discover automation. With its help, part of your work will be performed by written scripts. Entered one command – and you have already carried out several hundred checks, and the results are uploaded to a beautifully created report.


Testing is an interesting job, sometimes routine, but always useful. From project to project, I learn and study something new, that is, I constantly develop as a specialist. I always clearly see the results of my work and know that thanks to me people get quality work products. It feels nice.


Web and mobile testing differ in various types of tasks.

Testing of mobile applications is very much tied to the features of the device since modern smartphones have wide functionality and a large number of additional devices: headphones, SIM cards, Bluetooth devices, styluses, external batteries, and so on.

Web application testers bypass this and work with chrome, firefox, and stuff like this. Their task is to verify that the product works correctly in all browsers declared by the customer and in the required range of resolutions.

How to choose? If you are interested in solving non-trivial problems and looking for new approaches, then go to a mobile one. Thanks to a large fleet of devices and a certain set of versions, you will constantly come up with unusual cases for testing.

If you like to sit quietly in a comfortable chair and not be distracted by stranger things tasks, then the web is more suitable for you. In this case, all your tools will most likely be within the workplace.

The best-case scenario – try both and choose what you like the most 😉