Building your own device farm
Why a device farm?
The question that was asked the most: why invest in a local device farm now that cloud technologies abound? The answer is simple: it’s worth it. Smaller companies often have limited budgets and a local device farm allows you to maintain the quantity and, most importantly, the quality of your testing through a one-off expenditure.
The longer version is a little more specific: given proper research and analysis, you can manage a solid device pool with a modest budget, saving hours of manual testing. Building out your own farm does not exclude a cloud solution like Saucelabs. Think of it as an extra Lego brick: both technologies complement each other. The device farm provides faster feedback and makes the application visual and tangible. On the other hand, the cloud platform handles exotic configurations more easily, expanding the scope of your testing.
Targeted set-up
Your project largely determines the setup of your device farm. An important detail is that if you want to save costs, you should use the most popular devices of your target audience. In addition, usage determines your modus operandi. Will you support one specific application on the device or several?
Building a device farm presents interesting challenges. First, the size of your farm is a major difficulty: fortunately, with two devices and a host machine, you can provide a minute set-up. Second, the configuration learning curve is quite steep in the beginning. Once settled in, you know your chosen configured set-up inside out. Finally, tuning it and building in stability are the final technical hurdles to a well-maintained and reliable farm.
Divide and conquer
After the successful technical set-up, we explored further possibilities. We coded a unique queueing system on the farm, creating the possibility of using multiple projects.
Another added value was splitting the devices in two ways. We created device groups and assigned certain devices to a group. An example is the ‘devices for 2020’ group. Subdividing by operating system was also possible, such as by iOS 14 operating system.
Playing with technologies
All of the above obviously needed some lines of code to work seamlessly. For the cooperation between all technologies, Refleqt wrote a Jenkins plug-in that drives the device farm service towards Appium, which thus started and unleashed the tests on the applications.
Our node agent on duty was the MacMini. We configured the agent so that afterwards it was child’s play to recognise other node agents, or mobile devices and connect them to our device farm.
This keeps us very flexible, allows us to adapt our farm to the customer’s needs and tackles all bugs without any problems.