Are we testing mobile phones correctly, or what should QA pay attention to?
Contents
For some, testing is the easiest way to get into IT. And for others, it’s a fascinating pastime: to look for all sorts of jambs and mistakes in someone else’s work, to think through scenarios for people’s behavior. What if you do that or that? How about pressing this button?
However, sometimes even this interesting process becomes routine. Especially when the errors become the same. Therefore, we decided to compile a guide of the most common bugs so that the developer can check himself.
First, the evaluation
Where does QA work begin? First of all, he sits down for documentation, then evaluates the readiness of the project that fell into his hands, according to the following points:
the readiness of the application or its individual components,
project timeline
current priorities
“
Do you need to fully test the application? Or just look at a specific module (for example, a catalog, adding a product), or just tidy up the board?
The second is functional testing
Okay, we have evaluated our tasks, let's move on to functional testing. Here, the first step is to check whether the application performs the task that was intended by the customer.
Agree, why check how the application works (we are talking about non-functional testing: performance, security, usability ...), if it generally does not perform the functions assigned to it?
After functional testing, we go to check problem areas in mobile applications, taking into account their features. About them further and will be discussed. Let's take a look at both Android and iOS.
What hurts the phone?
Screen orientation
1
Remember, there are users who use auto-orientation. They will be the first to catch this bug: if you tilt the device a little while using the application, will the buttons, pictures, text, etc. float.
Agree, no matter how cool the application is, such a jamb will undoubtedly leave a negative aftertaste. Therefore, when testing a mobile application, this is worth checking first.
2
If the application provides horizontal orientation, then the testing area is greatly expanded. You need to carefully go through all the screens, dialogs, pop-ups and notifications twice. See how all possible content is displayed in both vertical and horizontal orientations.
3
It's a good idea to check how the application behaves if you turn the device over while viewing a photo or entering text. There were cases when the text typed by the user simply disappeared when rotated, and the photo was stretched or did not fit on the screen ????
4
If there should not be a horizontal orientation, you should make sure that it is disabled in the application and check it on 1-2 screens. There is nothing to check the entire application for orientation.
Light/dark theme
Everyone chooses a color theme. Someone does it for convenience, and someone - for the sake of saving battery power. By the way:
Google compared power consumption at maximum brightness for normal mode and dark mode in the Google Maps app. Nothing has changed for the iPhone 7, and the power consumption of the AMOLED Pixel has dropped by 63%. So it was proved that the dark theme significantly reduces the load on the batteries of smartphones with OLED screens. BUT everything is not so clear, because the battery consumption decreases only on smartphones with OLED displays and only when using black pixels. Since on these types of displays, the black color of the pixels does not expend energy to display them, the pixel is completely turned off.
Let's get back to testing the dark/light mode.
1
Does the app have a dark theme? If “yes”, we compare with the design, pay attention to the color of buttons, text, buttom-bar, dialogs and pop-ups.
2
Beware of black text on a black background, or vice versa. The screenshot below shows how the black buttons look on a black background...
IP Camera Video Playback App by Yi
3
Track how text, buttons, and application menus are displayed.
screenshot of JBL app
By the way, this is the official JBL mobile application. Both adjacent buttons are inactive, but for some reason one of them is practically invisible. By the way, the owners of this column and Android 13 were a little unlucky, because. with the latest update, I can’t connect to the column ...
How is the typed text displayed in inputs? For example, with Xiaomi had such a situation. Dark Mode was first shown in MIUI 11, and already in MIUI 12, Dark Mode 2.0 appeared. But the dark theme did not work adequately in all applications. So, on Facebook and Snapchat, people caught bugs where, when the application starts, the background remains white, and the font color changes from black to white. As a result, nothing is visible.
Now, in order to continue using applications on Xiaomi, you need to go to the Dark Mode settings and disable the dark theme specifically for those programs in which it does not work correctly.
Do you think Xiaomi moved to release a hotfix on this topic? It wasn’t there. The Mi Community said that because Dark Mode only works incorrectly in third-party apps Xiaomi is not in a hurry to fix this.
In my reality, I have to deal with bugs when for example white text is entered on a white background in the input (text input field) - It looks something like this:
4
Don't forget to check how the content of the notification shade is displayed. It happens that the battery with the clock is not displayed, etc. Or sometimes when some modal appears, everything that was in the blind disappears.
Communication breaks
What happens when the Internet is weak or completely disappears while you are “walking” through the application or trying to place an order or try to add to favorites?
1
Check out how the transition from WiFi to mobile Internet is going on and further work: ordering, saving, etc.
2
Do not forget to test the display of alerts in the complete absence of the Internet (and not just a spinning loader, ignore the request, or, even worse, crash). Do it at least on the most important screens of the application.
Uploading a photo or any other files
This is a real pain in testing lately. For example, on certain versions of Android, photos are not attached at all.
If we look at this topic as a whole thing, then it is important to consider several things:
1
Any files on a mobile phone will be downloaded mainly using mobile Internet, which is not always good. Therefore, it is important to check file uploads with Throttling (e.g. in Charles) and make sure that the request does not time out.
Let's imagine a situation when we are testing sending a file in an office with good internet. Everything is cool - and the application flies into production. The user is trying to do the same in the underpass. The file might have reached it, but it failed due to a timeout (i.e., the request fell off, because its lifetime has expired). But it was only worth increasing the waiting time for this request from 30 seconds to 60 (depending on the need and the type of file being loaded).
2
The specifics of attaching a file on Android and iOS are different. Check this process on both devices.
For example, on Android, you can attach at least 3 ways (through the gallery, explorer and taking a photo).
There are problems when the file simply does not attach.
There are problems when the file simply does not attach.
3
It is worth clarifying about the validation of uploaded files both on the backend and on the client. It makes sense to limit the size of the uploaded file and inform the user about it even before he receives a negative response from the server, otherwise the situation will look like banter.
If a user tries to upload a 15Mb photo, then either the application should say that the photo is large. Or do not say anything and do not limit, but simply artificially shrink the size of the photo before sending it to the server.
4
If you send several photos at once (for example, when creating a product). It is worth thinking again that using the mobile Internet will take a longer time. Therefore, some kind of progress-loader is required so that the user understands that everything is fine and nothing is frozen.
All those sub-items can be combined into one situation and give an example of common bugs:
To add an ad, the user uploads 5 photos taken on iphone 13, each of weighs 10+MB. What bugs can be expected? The user waits a very long time until the request sends and:
sees an error in some other field, corrects the error and again waits a long time for all the photos to be resubmitted, hoping that this time everything will be fine
gets an error validating the uploaded file (why then did we upload it for so long, so that in the end the server would not accept these files ..?)
the request falls off on a timeout. Here, either user sees it and tries to send it again, or, even worse, he does not see it. And for user, photos are sent endlessly.
Any of the results (and I'm not afraid of this word) is terrible for the user.
5
File upload error. In case if something goes wrong, don't forget to let the user know. It's bad if the application displays unsuccessfully sent photos as delivered. Watch the requests and don't rely solely on the successful response of the application itself. Or when the image being sent just disappears. In this case, the user sees neither the error nor his photo. And he doesn't understand what happened.
Now let's imagine a situation where a user wants to contact tech support, attaches a screen of his problem - the photo does not upload. We couldn’t help the person, and instead of solving the problems of our user, we give him an even greater portion of negativity.
Disable important buttons
After the first pressing of buttons, such as "Place an order", "Send a request", "Register", etc. they must be disabled so that the command cannot be executed twice until a response is received from the server. This can be checked immediately by running a positive case. The main thing is to get into the habit.
Let's imagine the case again, when the user presses the "Place an order" button, the request takes a long time, an inexperienced user can try to press the button again without understanding the principle of the application. In the worst case, the result will be an error display, as on repeated request the server shouldnt react the same way. The user may think that something is wrong with his order, although it was created without errors from the first request. Or the order will be issued twice, which is also not good ...
Minimize the application to tray and return back
What bugs can you meet on your way in this case?
when the application returns from the tray, visually you find yourself on the authorization screen, while before collapsing you were already authorized.
during transferring you to the payment screen, you’ve closed the application, and upon returning you were in the cart again. Empty or not, it doesn't matter, it still confuses the user. User does not understand whether he has placed an order, and what to do next.
Another situation: you place an order, the application displays a webview (bank web page) with a form for specifying a card, the user collapses the application to sees a photo of his card, returns back, and this page is no longer there. What happened? Order created? But I didn’t pay for it… Create again or write to technical support..? No, I'll order elsewhere. ????
Checking the display of text and content at different text sizes in the OS
1
On average, applications use approximately the same font size, which is optimal for reading. And yet, do not forget about people who increase the size of the letters for one reason or another. In such cases, the text in the application may go beyond the boundaries of the blocks, or the pictures and the name of the buttons will not fit. For example, such bugs can be encountered in the Kufar application:
2
It's good when the application has its own font size, which is not affected by the OS settings. But this is not justified in all cases. Sometimes its choice directly depends on the subject of the application and the target audience.
Testing the back button on Android
Implementing a rollback on Android is different from iOS. There may be situations where this option should not be available. For example:
Logged in and clicked "Back" - you should not be logged out.
Received bonuses, pressed "Back", again ended up on the screen for receiving bonuses.
“
When I was studying, I found a real game from PlayMarket (from production). There was a bug when you receive a prize, you press "Back" and you find yourself at the last step before winning. Again you do this step, again you "win" and again you get victory points.
Remember to clarify what the behavior should be if you are on one of the main screens and press "Back". Should the application be exited, or only with a double click, or with a single click should you be returned to the main (main) screen?
Standby mode
You used the application, put the device aside, and after 1.5-2 hours they continued to use it. At this stage, bugs often appear. In most cases, this is an application crash. Usually, this is due to the library used in the application, or a memory leak.
Content padding on iOS and Android
1
Often a developer, while implementing the functionality, looks at what happened only on one device. And it turns out that they pay attention to indentation only on iOS (for example), while on Android it may look like this: (screenshot)
2
In this context, let's remember scrolls. Often bugs arrive when you scroll not across the entire part of the screen, but only in the center. On this screen, the area where it is impossible to scroll through the list is highlighted in red
3
Separately, it is worth noting the importance and necessity of installation testing, but this is a topic for a separate article.
Summing up
This all works good in theory and ideally all this should be followed. For example, look into this checklist for both QA and the developers themselves. But, unfortunately, hands do not always reach this and there is not enough time for this ...
If there were other popular or interesting bugs in your practice, write comments, we will supplement this guide.
