Optimizing device fragmentation testing

There are a number of issues that are regularly cited as the main problems with testing mobile apps: fragmentation of devices/manufacturers, OS versions, networks (changing connection types and speeds), usability, testing tools, automation and security. Whilst some are complex and require skilled and experienced testers, some of these can be overcome with a bit of knowledge of mobile apps and a good plan. I want to talk about one specifically and offer the benefit of our experience.

The fragmentation of the device market, especially Android (although more recently the iOS family has grown as well!), is overwhelming. You can find infographics that will graphically display the overabundance of devices. How can you test all these devices, and if not, how do you choose a reasonable set of devices to test?

For the purposes of this article I will focus on Android devices, and I am not considering OS version. The principles are the same whatever the platform is.

1. Factors

There are a number of key factors that we will need to consider:

* Screen size and screen resolution

* Device manufacturer

* Carrier

* Processor chipset

* Memory

* User demographics

* App design

Firstly, lets get rid of the least important ones starting with device manufacturer and carrier as these have very little impact on the performance of the app; we find very few issues that are specific to either of these factors. And you can cover a number of different manufacturers when making your device selections anyway.

Processor chipset and memory will affect the performance and that is why you need to consider app design. If your app is primarily downloading content from a web service and displaying it in a simple UI, the biggest influences on performance are network bandwidth and web service performance. The device performance will not have a significant impact. If your app is a UI heavy game, then you will need to test on high-end and low-end devices.

The profile of the expected users of your app will also have an influence: are you expecting affluent, low-cost, or a wide range of users. And then you may not have that information to be able to make a choice based on this factor.

Screen size and resolution are the biggest factors for most consumer apps. This also includes aspect ratio and portrait/landscape rotation. Designing your UI to work across the range of possibilities effectively whilst maximizing the appeal of your design is a challenge. The size and position of buttons and other user input controls, dynamically resizing UI controls and text, and scrolling and zooming controls are just some of the issues that you need to test for.

2. Selection Method

One of the most useful pieces of information you can have for selecting your set of devices is usage data. The volume of sales for each device is interesting but far more useful is, what devices are being used with apps that are similar to yours. If you have a mobile-friendly website that is being used by a similar group of users to those you expect to use your app, you can look at the profile of devices from that. If not, there are a few places that publish usage data by device type. You can look at those and decide whether they are close enough to your app. This will give you a long list, with each device type probably only accounting for a few percent of the traffic.
Next you need to find the screen size and resolution for each one – this may take a while first time round. Then if you are repeating the exercise every quarter, the number of new devices that will appear in your list will be relatively small. Once you have the screen size and resolutions, you will see that the devices will start to fall into groups. You can then select a single device from each group to represent that group.

How do you select which device represents each group? You then consider the following factors:

User profile – If you have a specific target group of users, does this affect your selection based on the price of devices? (Make sure your original list of devices was relevant to the geographical area you are considering.)

App performance – Is there an aspect of the app that will be affected by the processor, graphics chip, or memory? If so, select from high and lower performing devices.

Manufacturer – Select from a range of manufacturers.

And finally, pick devices you want to test. If there is a device that has just been released so it won’t appear on historical usage stats and despite that it is interesting to you, pick it. I’ll talk in the test planning section below about how you can test additional devices without significant extra effort.

3. Test Planning

Let us create an imaginary test suite that is 40% functional tests, 10% performance tests, and 50% UI tests. You have selected six devices to test. One approach you can take to avoid running every test on every device is to spread the functional tests across all six devices, running each test only once per cycle of testing. In subsequent test cycles, you can swap the devices used for a test to gain more coverage.
The UI tests can then be split into two sets: those that are unlikely to be affected by screen size/resolution and those that will. Again, you can spread the first set of tests across all six devices. You are then left with only the UI tests affected by screen size/resolution that you need to run on all devices. If you have performance issues for the app, then you would run the performance tests on the highest and lowest performing devices.
With this risk based approach, you can reduce the amount of testing from all tests on all devices by 60%.

4. Conclusion

Device fragmentation can be daunting when you first consider it. However, with careful consideration of the parameters of your app and your target audience, and systematic analysis of the available devices, you can achieve wide coverage without an excessive increase in testing effort. Or you can engage Atimi’s QA team and we will work with you to create and execute the optimum test suite.