The most important question for every development team is always "how to achieve product quality"? No matter how perfect the development tools are and no matter how highly-skilled the developers are, there should always be a place for testing in the development cycle.
First of all, let's define that testing is the process of comparing the actual behavior of the product with the expected one. It sounds pretty simple and straightforward, but in reality, as always, everything is different. Testing an application does not only consist of making a couple of double taps and delivering a verdict right away. It is a process, which requires an ability to critically think and attentiveness, as well as creativity and curiosity.
Our company works with many different platforms, but today I want to concentrate specifically on the testing of mobile applications. We will be discussing the things that everyone loves – smartphones and tablet devices. We can hardly imagine our life and business management without them, because nowadays an app, which is available in App Store and Play Market is almost a must for most of the business projects. Since there is demand, there will also be supply.
The process of creating a mobile app undoubtedly differs from other types of projects, such as creation of a web site or a CRM. Both the technology stack and the design approach will vary (UI/UX, by the way, is also tested!). Of course, there are some special aspects of testing mobile applications. We will try to analyse the most interesting of them.
First of all, we take into account the specifics of each platform (iOS and Android) as well as their versions. An application can be developed for both platforms at the same time, but the particularities of each OS will affect both the development and testing, because the behavior of the application may differ depending on the OS and its version. For example, let's compare the highlighting of SMS messages in iOS 12 and iOS 14. On iOS 12 the highlighting simply occurs with an appearance of a drop-down menu, whereas on iOS 14 version has a new component contextMenuIntegration, when you use it, animation is rendered with blurring of the background, when the message remains in focus.
A similar difference can appear in your projects, animation will look different for these two OS, although the functionality in question remains the same.
In addition to the OS, you should pay attention to the physical characteristics of the device, in particular to the screen diagonal. It will be quite unpleasant if the app layout breaks for the users with small screen devices, whereas everything will work fine with larger screen devices. On top of that, hardware can also affect performance. Some applications can require the use of computing power of the hardware, which will impose certain optimization requirements. Therefore, we must not forget that testing should be performed both on powerful and large devices, as well as on small and relatively weak ones.
Wi-Fi and mobile data, the functionality which makes your smartphone truly smart, should also be mentioned. If the application requires an Internet connection to function, it will be necessary to work with the capabilities of mobile data or Wi-Fi. By themselves, they do not produce any problems. If the connection is established, for example, an application can steadily communicate with the server. But special cases here arise exactly when Wi-Fi and mobile data begin to interact with the app simultaneously. It should always be tested how your application handles a reconnection from Wi-Fi to mobile data during its use. Some technologies require that this case has to be handled separately, otherwise it will not work correctly.
But what about manual testing? What tools does a tester use when he is performing such a task? When we talk about automated testing everything is rather clear. This is where the code is being worked on, a separate area with its own particularities and utilities.
Manual testing has its own instruments too. These are test management systems, like TestLink, mobile device emulators and various approaches (a checklist, for example). I would like to talk particularly about API testing tools such as Postman and Firecamp, as well as Charles and Fiddler sniffers for traffic monitoring.
Let's start with the first one. When we mention an application that also needs to store some data on the server, we mean not only its client part, the device itself, but also the server. In such a case, we test the server, including its API. There, Postman, an indispensable attribute of any tester, comes to our aid. It allows you to create requests to the server, work with them, track responses, even create collections to automate this process. All of this without using a smartphone!
However, we still need to test the API sometimes, and in some cases we can't do it without using a smartphone. An example would be a situation, when an authorization token is generated with the use of a smartphone, which can't be received otherwise. In a situation like this we will need to know how our server responds to us. There Charles and Fiddler sniffers come to our rescue. If we proxy smartphone traffic through a PC, the sniffer is able to monitor requests from the client to the server and responses from the server to the client. This way we can acknowledge the way the server responded to an authorisation attempt or something else. In addition to that, Fiddler can even emulate a response from the server, in order to see
Some more examples. Let's stray away a bit from specifics and imagine that you are a tester in a certain company. Your project is a mobile iOS/Android application for your company, and you are in charge of testing it. A task comes to work, which will be the object of further analysis. You, a responsible tester, are well aware of the current requirements and start the testing process. Following your list of checks that are needed to be performed, you describe the actual behavior and evaluate the application's performance within the framework of a given task. Suddenly, you observe behavior that is different from what you expected. What will be your algorithm of further actions?
Let's say that the encountered bug is rather serious, the one that requires a separate task to be created to resolve it. First it is required to figure out which side of the problem is, on the server's side (Backend) or on the client's side (iOS or Android)? This has to be done in order to preoccupy a necessary department with resolving this task.
If the bug is visual, then most likely the problem's source is in the client platform. What if the bug is related to the logical behavior of the application? Either a simple behavior analysis based on the knowledge of the application architecture will help you here, or Fiddler, which will allow you to understand, whether the server responded incorrectly to the correct client request, or did the client incorrectly perceive the server's response? Having dealt with this, you can safely assign the task to the desired department, of course, with a clear name, full description, steps, actual/expected result and, if possible, screenshots or videos. Congratulations, you have dealt with a bug and made your product much better! :)
Now you have learned about the interesting features and stages of testing a mobile platform. Why is this useful in particular? Why does the testing make your product better? If we don't take into account the fact that the tester finds and localises the defects, the answer is pretty simple: Price. The sooner a problem is found, the cheaper the solution will be. A bug found at the release stage may take much longer to fix in comparison to the one found at the first stages of development. Plus, the user, of course, will be more satisfied.
At Doubletapp, a testing department was established at the beginning of this year, the need in which had arisen due to the appearance of many large projects that required to be tested. It paid off very soon. More tasks began to be resolved, developers began to perform more tasks without wasting time on testing, and testing itself became much better.
It is also worth mentioning that testing of mobile applications has become a new highly demanded service that our company now offers. In addition to us supporting projects from our customers, there is a great demand for outstaff testers coming from various companies, thanks to which we ameliorate our outstaff competence and field experience of our employees, becoming even better every day.
I hope that I have revealed some of the secrets of mobile application testing for you. It should be noted, however, that it's always better to comprehend everything through a personal experience. Discover, discuss things with colleagues, try new things.
And may quality be with you!
Discuss article on social media