As for August 2015, there were more than 24,000 different Android devices and we can only imagine that that number has been growing over the past year. While waiting for this year’s Android device fragmentation report, we can show you how it looked like in 2015.
All of these devices have different size, shape, and hardware, as well as software which is a whole new set of challenges.
Screen size and OS fragmentation
Although we were talking about Android device fragmentation above, mainly because Apple has fewer devices, we can count both of them in when talking about screen size fragmentation. Many of those 24000 different Android devices have a different screen size, but Apple has many screen sizes as well, ranging from 3,5” of the iPhone 4, which is still a popular device, to the 12” of the iPad Pro. So it’s not just Android that is fragmented.
Together with the screen size fragmentation, we have to also talk about the OS fragmentation and the different versions there are, based on geolocation and manufacturers. People can still be using very “old” mobile devices and buy devices with older OS versions with no means of updating them to a newer one. Android has still 11 different OS versions circulating.
Modifications to the OS made by the manufacturers make everything more complicated. Apple has fewer obstacles in this department, but developers and testers have still to face mobile devices with iOS 6.0.1, which does not get updates.
Another difficult thing to master is the manufacturer fragmentation. In 2012 there were “just” about 500 mobile device manufacturers, but in 2015 that number more than doubled, reaching 1200 different manufacturers.
This fragmentation in manufacturers can be seen in the device fragmentation overall, which is not just about the device look, but also in the hardware and software changes that manufacturers use to distinguish themselves from the others. This small changes will affect how an app works, making testing even more important.
Localisation can be counted as one of the main mobile app testing challenges. It’s not just about the language of the app that can be changed, but how it interacts with the rest of the mobile device and how users feel about being able to change the app language to their own. Every language that will be added to the app should be seen as new opportunity to penetrate a new market but it still remains an obstacle to overcome.
Mobile network operators and users mobility
Directly connected to localization there is actual users mobility. People nowadays travel very often, changing network, roaming and making sure that apps work when users need them is crucial. This may be online or offline, with a weak signal etc. A typical example is mobile plane boarding passes. Let’s say you have a ticket/boarding pass wallet app and your user have saved a plane boarding pass in it and the app won’t open without mobile data – that user has no means to board their plane!
Different application types
Apart from all the mobile app testing challenges we have already mentioned above, there is one that is not specific to the mobile devices but to the app. Apps need to be tested in different ways because mobile apps can be built differently: they can be native, hybrid or web application (mobile-designed web pages). All of these elements play an important role in how the app will be tested.
Many different testing tools
Another obstacle for developers and testers is the choice of the right tools for mobile app testing. There are so many tools out there that it is impossible to choose from unless you have a mobile testing strategy and you know exactly what you need to make your testing plan happen. You can read about our favorite testing tools here.
Agile development is not a mobile testing challenge per se, but it is one challenging aspect of developing a mobile app because the development process of mobile apps should be an agile one, to react quickly to changes and to user’s requirements. Becoming agile means to gain agility during the whole process and that can be done day after day, improving the whole process, making small sprints for every new feature/bug fix, turning the whole process to a more dynamic one.