Identifying and procuring the right devices for the testing need is an important first step. However, it is just the start of a continuous maintenance cycle. It is not uncommon to have around 30-40 in-house devices in the team. Maintaining these devices is a massive challenge in itself. Let us explore some of the problems of maintaining a device lab for the mobile app testing.
1. Mobile devices can go missing easily, secure them
Let me be clear, by implying security of the devices as a maintenance issue, I am not suggesting that people working in the office are thieves and you should start doubting them. Some of the high-end mobile devices are very expensive, and if there is a significant number of devices, it just makes sense to think about the security of these devices. There may be security breaches or accidental misplacement in the absence of a sensible security policy. Also, a defined security policy would make it easier for everyone to find and access these devices when needed.
2. It is difficult to find a device with the right configuration, label them
Imagine if you need to find an iPhone 5s with iOS 8.4.1 version in a maze of iPhone device. In the absence of any labelling system in place, it would take a while to find the right device for the right version of iOS. If you, and your teammates, have to spend 10-15 minutes every time you need a device, it is a waste. It would be good to have vital information about the device, such as OS version, device name, model number, storage, etc. on a label that can be stuck on the device. If you have a rack where you can store these devices, you might want to organise these racks according to devices, OS, and so on.
3. Label on the device and the device configuration do not match, update labels frequently
Putting labels on the devices is an important first step. However, it is important to ensure that labels are updated and do not give the wrong information. Most of the OSes and applications can push upgrades rather aggressively, and it is important to ensure that test devices maintain the version numbers they are provisioned for and not upgraded frequently. If devices are upgraded, it should happen consciously, as a managed task that should only be considered done when the label associated with the device is also updated. It would be nice to automate this process, maybe with an app that can send device information to a confluence page periodically? In case you want to build one, here is an idea 🙂
4. Who has got the iPhone 4S with iOS 8? Maintain register
People often have a legitimate need to take the device to their desk, or even out of the office. In the absence of a device register, that can give us information on who has got a device; It would be very tricky for the team to get hold of the devices they need. It might feel that maintaining a device register and asking your teammates to sign-in and out every time they take a device for testing is overkill, however, It might bring accountability and predictability in the team. Defining a process and ensuring that everyone adheres to it would help a lot in keeping track of these devices that can get lost easily in an office corner. If resources permit, it is possible to take the pain out of this process by following an RFID-based approach that Etsy use to track the devices in use.
5. Device register goes out of date, make someone owner
Maintaining a device register and ensuring that the right labels are used for the racks and devices is an essential process for the mobile testing lab. However, in the absence of an owner for this process, it might become a bit tricky to ensure that everything is in order. It might be useful to create a role (rotate it monthly, maybe?) that take ownership of auditing devices periodically. The primary goal of setting up the device lab is to be able to get the devices we need predictably and reliably. Making someone accountable would make it easier to ensure that devices are maintained as they should be.
6. Devices you need are always flat, keep them connected
A mobile device without any charge is as good as a brick! It is a significant challenge to ensure that the mobile devices we have for testing are charged and can be used when needed. Remember, some devices can take ages to come back to life if their battery is completely dead. Managing power cables for all these devices, considering that most of them are incompatible with each other, is another challenge. A mobile device rack that can hold all the power cables connected to a USB hub for charging all the devices might work well. If you do have a solution like that in place and have your mobile devices at 100% charged all the time, make sure that you mimic low battery conditions as well. Mobile devices do act differently depending on the battery level.
7. Can not install the test app from the TestFlight and Crashlytics, use the same account
Many teams use systems like Fabric or TestFlight to distribute test versions of their applications to the internal or external beta testers. For these systems to work effectively, devices have to be logged in with an account that is registered or approved on the Fabric or TestFlight. These systems need to know who will get access to the application. It is important to ensure that all the test devices are logged in with the right account. If that is not the case, it might not be possible to install test versions on these devices when needed. A visible policy page (confluence or something) or a shared password manager can help solve this problem.
8. Got the device, how do I unlock it? Share passcode or pattern
In a mobile device testing lab with 30+ devices, it is impossible to imagine that everyone in the team will be able to remember the passcode or the pattern. We often use an easy to remember passcode such as 0000 or a pattern such as a horizontal line to ensure that it is easier for the team to remember it. Also, it might be worthwhile for the device auditor to check this time to time and ensure that it is still valid and updated.
9. I can’t reproduce customer reported defects! Keep phones in the normal condition
What is the normal condition for a mobile phone? Well, it turns out, there is not any normal condition. Some people have tonnes of apps, photos, videos, etc. and some people have hardly any. The number of apps, available storage space, and battery level vary considerably for different users. These variations can affect how much resources are allocated to your mobile apps and as a result, how it performs in the wild. It is impossible to mimic all the possible combinations of the storage, memory, background apps, and so on, however, we should ensure that all of the test devices in the lab are not on the factory settings. They should have some level of variations to represent some common patterns.
10. Can’t access the Internet from the device. Remember reset
During our day-to-day testing activities, we often need to configure mobile devices to use a proxy server such as Charles to see the traffic and manipulate the response mobile apps can receive. However, if they are not reset properly after testing, other people may not be able to connect to the network and waste time in figuring out that the device is configured to use a proxy that is no longer running. Remember, non-technical people might also need to use the devices to test or demo the applications, so it is a good idea to keep all the devices in good condition. Similarly, if regions, locals or time zone is changed, it may have an effect of the app and it might be tricky for people to identify and rectify the situation. A good rule of thumb would be to specify a base state and ensure that all the test devices are in the same state.
These are some of the challenges I have encountered in maintaining a device testing lab. If you are managing or in the process of setting up a mobile testing lab, you might find this list useful. Also, it would be good to know the challenges you have faced and the ways in which you have solved them. Please comment to share and discuss with all of us.