5 principles of testing mobile applications
Immediately I will make a reservation, everything I have described below is derived solely from my small amount of time spent (but large in terms of the number of job seekers, misadventures and other batthurts) experience. Reservation number up: these principles apply only to mobile software. How are the others - I do not know and do not want to guess. And the last, perhaps most important. These principles only set the direction, and therefore will be useful mainly for beginners (although you, of course, can write about the uselessness of this article in the comments).
So, when I first started testing, read an available theory, the head started the second interview with a simple question - what is the feature of mobile testing in relation to other types of testing? Then I could only approximately answer this question. Now I highlight the following principles for myself:
The main difference between mobile and desktop software is that with an iPhone you move around, vainly catch Wi-Fi in the canteens of your universities (making characteristic hand movements), run and generally load all possible motion sensors to the maximum that the Chinese craftsmen have built into it. Forget death like that. Someone may say that it is stupid to run around the office, changing the orientation of the screen and losing-restoring the connection. To this I have 2 counter-examples from life:
')
Most modern applications, one way or another, use the network. Not always a “full connection”. Therefore, it is imperative to test the application in at least 4 ways:
Most users are unlikely to see your crashes, but may stop using the application if it loads badly and saves data during their (users) connection problem. In case of a lack of communication, at least some placeholders must be displayed (so that the user can understand that the application cannot load the data now). Well, sweetie for the tester - loss of communication. Users will experience this all the time, and the most important thing here is to avoid data loss whenever possible.
In an amicable way, this principle should be at the top of the list. After all, interruptions cause the most significant damage to the application, while being one of the fundamental principles of the mobile systems themselves. While using your application, the user may
The reaction of your application to these stimuli should be checked immediately after functional testing. Here lies the abyss of interesting situations from harmless (the interface has moved a little) to critical ones (the application drops, data is lost, full Achtung).
This principle is here with an obvious stretch, but still, I believe that the OS and hardware installed in mobile devices affects the software performance much more than in desktops. Why?
If the application is designed for a wide audience, be prepared for the fact that a bunch of people, infinitely far from software development, will behave quite differently with your application. It is important to understand here that we cannot calculate all possible cases of application use by all Krivoruk users. But we are obliged to check that the application correctly performs all of its functionality on the basic juz-cases. It is also good to protect yourself by running through the application as a dummy user, poking at everything, opening and closing activities, without waiting for data loading, etc. The problem with the “zamylenny eye” is solved by involving your girls, friends and relatives in the process. Just give them the app in their hands and see how they will use it. This will give you an approximate (how much approximate it depends, of course, on the size of the sample) a picture of what should be tested first and what to look for.
Of course, to a certain extent this selection of principles is subjective and controversial, and perhaps this article will seem frivolous or incorrect (to me and to you). On the other hand, I hope that the article will still be useful and will help you to concretize and not forget the things that are most important when testing mobile applications. And finally, I would like to share experiences:
What principles of mobile testing do you use?
So, when I first started testing, read an available theory, the head started the second interview with a simple question - what is the feature of mobile testing in relation to other types of testing? Then I could only approximately answer this question. Now I highlight the following principles for myself:
Principle 1: Continuous Mobility
The main difference between mobile and desktop software is that with an iPhone you move around, vainly catch Wi-Fi in the canteens of your universities (making characteristic hand movements), run and generally load all possible motion sensors to the maximum that the Chinese craftsmen have built into it. Forget death like that. Someone may say that it is stupid to run around the office, changing the orientation of the screen and losing-restoring the connection. To this I have 2 counter-examples from life:
- Crash in the application when trying to restore the application from the background with a preliminary change of screen orientation;
- Crash in the application while “shaking” the device at the moment of taking this photo by this device (the application was originally created to create a photo).
')
Principle 2: Fishing for live bait
Most modern applications, one way or another, use the network. Not always a “full connection”. Therefore, it is imperative to test the application in at least 4 ways:
- Positive case (the presence of excellent constant communication);
- The presence of a permanent non-personal connection;
- Lack of communication;
- Loss of communication.
Most users are unlikely to see your crashes, but may stop using the application if it loads badly and saves data during their (users) connection problem. In case of a lack of communication, at least some placeholders must be displayed (so that the user can understand that the application cannot load the data now). Well, sweetie for the tester - loss of communication. Users will experience this all the time, and the most important thing here is to avoid data loss whenever possible.
Principle 3: Interrupts
In an amicable way, this principle should be at the top of the list. After all, interruptions cause the most significant damage to the application, while being one of the fundamental principles of the mobile systems themselves. While using your application, the user may
- Unexpectedly receive a call (SMS, reminder, notification, etc.);
- Close the application to open something else for a while and return to your application later;
- Send the device to sleep for a while.
The reaction of your application to these stimuli should be checked immediately after functional testing. Here lies the abyss of interesting situations from harmless (the interface has moved a little) to critical ones (the application drops, data is lost, full Achtung).
Principle 4: Features of operating systems and hardware
This principle is here with an obvious stretch, but still, I believe that the OS and hardware installed in mobile devices affects the software performance much more than in desktops. Why?
- Android and Apple OS are significantly different from desktop systems. Activities (and their stack), intents, Broadcast receivers, manifest file (with permissions and user features), access to resources, cache and application data - all this and much more needs to be studied at least fluently in order to understand how The application works in this particular environment, which can lead to its (application) failure or data loss. This results in testing the transition between states, testing to find memory leaks, and so on. All this is necessary to fully ensure the quality of the application.
- Progress does not stand still, but the hardware of smartphones is still very limited compared to desktop systems. It is especially important how much your application takes up RAM, under what conditions the system will automatically “cut it out” from this very memory, how the application will behave in this situation.
Principle 5: The Human Factor
If the application is designed for a wide audience, be prepared for the fact that a bunch of people, infinitely far from software development, will behave quite differently with your application. It is important to understand here that we cannot calculate all possible cases of application use by all Krivoruk users. But we are obliged to check that the application correctly performs all of its functionality on the basic juz-cases. It is also good to protect yourself by running through the application as a dummy user, poking at everything, opening and closing activities, without waiting for data loading, etc. The problem with the “zamylenny eye” is solved by involving your girls, friends and relatives in the process. Just give them the app in their hands and see how they will use it. This will give you an approximate (how much approximate it depends, of course, on the size of the sample) a picture of what should be tested first and what to look for.
Instead of conclusion
Of course, to a certain extent this selection of principles is subjective and controversial, and perhaps this article will seem frivolous or incorrect (to me and to you). On the other hand, I hope that the article will still be useful and will help you to concretize and not forget the things that are most important when testing mobile applications. And finally, I would like to share experiences:
What principles of mobile testing do you use?
Source: https://habr.com/ru/post/244345/
All Articles