VII (7) common mistakes every mobile developer does — by QA
Even Google, Microsoft and Apple make mistakes, and its human to make them. Quality Assurance can often be overlooked or not receive adequate attention compared to other aspects of mobile application development but it is an important part of the process.
In this blog, I will be presenting you with some of the most common bugs in mobile applications.
1. UI bugs
Page layout at different screen resolutions/densities
One of the common bugs is when the developer is testing his app only on one phone or on a few phones of the same size. This happens as a result of developer’s careless testing and not testing the app on multiple screen sizes. When the developers forget to do so, they get many bug reports from users with different phone sizes. Device models typically differ in size, resolution and OS versions. The app is supposed to be optimized for each screen size of the targeted phone sizes. Always check if everything looks good and works fine on different screen sizes.
Visual appeal is the feature a software never lacks these days. Deviations in app design break user experience.
Content
Inaccuracy in the upper/lower case, mismatch of the words/letters, orthography and grammar mistakes. All of those serious defects confuse the users and harm the company’s reputation.
Font
Although these bugs are more of a UI design bugs, they are typically placed in the bug reports.
UI is crucial to your customer’s use and purchase of your products and services. Even standardized testing makes sure that all the elements run smoothly.
Layout
Here the problems typically occur not only with the floated misbehaving layout, but also with trippy text. The bug also happens due to improper layout spacing (line-width or line-height), which bugs the user.
Portrait/landscape orientation of the app
The most common occurrence of this bug is once the user changes the orientation of the screen and the current state of the app changes. Within the android system, a specific screen component known as Activity may be destroyed with screen rotations, losing its current state. Thus, after the rotation, all previously selected checkboxes or drop-downs may get cleared. An increasing number of applications blocks the use of landscape view, however, this is often still a problem with applications that permit the horizontal view.
2. OS bugs
Every developer has encountered a specification that isn’t fully descriptive of what the client really wants, so iOS and Android developers may interpret it differently and come up with different solutions for the problem.
The specifications for the app often aren’t detailed enough to clearly say how a feature ought to be implemented. Therefore, if the developers from different platforms don’t communicate with one another, those features that aren’t clearly defined are sometimes implemented differently on different platforms. That happens because of lack of communication between the developers and between the developers and the client.
When the new major OS version is released, it typically increases the failure rate and there are numerous reasons why this happens. New APIs, features, even OEM customizations and upgrades give flakiness to the test foundation. As this is not “vanilla-Android” OS versions that we compared with android devices, OEMs usually provide those OS versions (with their stuff).
Not developing for the right OS
Operating Systems are among the most important factors which determine simply how well the software can be used on a device. Operating systems below certain versions are practically useless and most device owners have come to accept the importance of having an up-to-date OS.
When apps are created and released to the public, they’re designed to be compatible with certain operating systems and not with others. This implies that, depending on what OS your app is developed for, you’ll be able to either have access to almost all devices or you’ll be very limited in terms of your potential user base.
It is quite easy to make mistakes when developing an app in terms of the OS.
The first mistake is developing an app for an obsolete OS. For example, if your app is only compatible with an operating system that became redundant in 2013, your potential user base is made very small, as most users would have upgraded their operating systems.
It is, therefore, necessary to make sure that your app is compatible with the latest and most used operating systems on the market to ensure the widest possible user base.
With each OS update and release, your app must be reviewed and you need to make sure that it’s compatible with the new OS and if not, the necessary changes ought to be made to make sure that this is corrected.
3. Straight away signups
Remember, the signup is not the endpoint of your app, but the gateway to the actual functions. Think of it as a doorway, keep it streamlined and make the process as fast as possible. The faster you get the users to the other side, the higher your chances of retaining them. Nobody wants to fill out a form with every field mandatory or having to fill a form for a number of minutes simply to give up on it.
As soon as users open an app, they are requested to sign up. This is often not recommended. You provide some features to non-registered users and some sort of an intro to using the app. Also, the options to sign up via Google+ and Facebook are much appreciated by the users. If you aren’t developing an app like “Instagram” or “Messenger” you shouldn’t use straight away signups.
VALIDATION FIELDS
Errors pop up once the user inputs the incorrect characters or exceeds the maximum field length. These bugs occur often and are mostly appointed low priority, as they’re not that crucial. However, sometimes they are, specifically, when the app has wrong or missing field validations.
It’s a good practice to limit the number of characters allowed for fields like number, postal code, city, country…
DATE CONTROL
For apps that use age restrictions, sometimes bugs associated with date control occur. Registration forms or profile editing forms may contain these bugs. To make sure that the app doesn’t have these bugs, a tester must test all test cases, the boundary date, as well as the dates that precede and follow it.
4. Slow network, GPRS, 3G, Wifi, airplane mode, APN settings, and no networks.
Most development and testing take place in a local network environment. Therefore, when you are downloading five background images, each being 3MB or more, you might not identify an issue with 1Gbit connection speed in your development environment. However, when your users start loading a 15MB home page over 3G connections on their smartphones, you should prepare yourself for a list of complaints and issues.
The speed of the network can massively affect the speed of your mobile application. If the network is slow, the app performance will also be slow.
Apps work differently when networks are slow or out of range. Everyone has experienced this bug, an app working improperly when we use it in the elevators, tunnels or underground parking lots.
The best way to test such issues is real-world network testing.
Testing the app on simulated network conditions is the best and therefore the most certain way to see how your mobile app will function across different network environments.
Changing the flow of data in the network is an easy way to simulate different network environments.
To test that your app is usable even with lousy bandwidth, tune your bandwidth consumption as much as you can.
Increase the latency to three or four seconds, ensuring any user-initiated operation is delayed by only a few seconds, rather than minutes.
Change the network’s bandwidth and connectivity mid-session while your test is running.
5. Error condition and exception handling
What if you try to purchase an item in the apps shop, but you don’t have enough money to buy it? This is the case where you must get an error message saying that the transaction is impossible and that you should add more to your account.
Any errors that occur while the user is interacting with the software need to be handled in a very clear and meaningful manner.
If an error happens and no error notification is sent to the user, this also hurts the end-user experience.
Displaying an error to a user is another important factor to remember. However, you also need to use caution as this action can reveal important information. It will benefit the programmer, not the user. That’s why an application was created for the user’s invalid credentials.
6. Progress indicator
To illustrate, a progress indicator is indispensable when the user is purchasing items from the shop. The user clicks to buy and sees that nothing has happened and so he clicks it again and again, having him purchase the item multiple times. This happens because there is no progress indicator or loading screen to show the user that the action is in progress.
Another example is when the user puts items in the cart, but doesn’t get any notification that the item is in the cart or there is no loading screen, so the user clicks “add to cart” again and goes to checkout only to see (or not see, which is even worse) more of the same items in the cart.
It is also necessary to feature a progress indicator to inform the user that an operation is in progress. There are many situations where actions last for a while and it’s important to inform the user that the operation is running right now. It’s best to indicate that with a progress indicator. This includes such situations as screen/content loading, long network operations on button click, like editing profile, uploading images, etc. An example of bad user experience would be if the user uploads an image to, let’s say their profile image, without a progress indicator during the upload of the image. The user may tap this button a couple of times repeatedly, thinking that nothing has happened and this also hurts the end-user experience. Showing a progress indicator informs the user of running operations in the apps.
7. Keyboard
Everybody has experienced this bug. Imagine clicking the EditText input and seeing your keyboard covering the text box, so you can’t see what you are writing. Programmers are sometimes careless and don’t test these bugs on different phone sizes, much like the other UI/UX bugs. These bugs also occur because developers use simulators to test and develop their apps. Testing mobile apps only on emulators is a huge risk because your users are running apps on real devices, not emulators. There are things that you just can’t find on emulators and simulators and that’s one of the biggest reasons that people use them in conjunction with real devices.
Start with making sure the right keyboard type is opened. Displaying a keyboard type adjusted to an input field type will be very helpful to the user. Another very important thing to consider is the password input type. A text password is not recommended. It is much better to use keystrokes for passwords.
An input method editor (IME) is a user control that enables users to enter text. Android provides an extensible input method framework that allows applications to provide users alternative input methods, such as on-screen keyboards or even speech input. After installing the desired IMEs, a user can select which one to use from the system settings and use it across the entire system; only one IME may be enabled at a time.
Missing out on these input methods can lead to bad user experience.
In conclusion, these 7 common mistakes are just the tip of the bug iceberg. Being a QA is a thankless job, but it is your job to tell developers when they are being careless or unwary.
There is nothing wrong with making mistakes, but one should always make new ones. Repeating mistakes is a hallmark of dim consciousness.
Thanks to Ana Šeler for the design!
Thank you for reading. Please comment, like or share it with your friends and we hope to see you soon.
Would you like to join us? Check out the open positions at our Careers page.
