Why a device farm?
The question most frequently asked: 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 with a local device farm you can maintain the quantity and, most importantly, the quality of your testing through a one-time expense.
The longer version is a bit more specific: given proper research and analysis, you can control a solid device pool with a modest budget, saving hours of manual testing. Building out your own farm does not exclude a cloud solution such as Saucelabs, BrowserStack or AWS Device farm. 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 setup
Your project largely determines the setup of your device farm. Note that if you want to save costs, you should use the most popular devices of your target audience. In addition, usage determines your way of working. 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 minimum setup. Second, the configuration learning curve is quite steep at first. Once settled in, you do know your chosen configured set-up inside out. Finally, tuning it and building in stability are the final technical hurdles to a maintainable and reliable farm.
Divide and conquer
After the successful technical setup, we explored further possibilities. We coded a unique queueing system on the farm, creating the ability to use 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 the above obviously also 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 that thus started and unleashed the tests on the applications.
Our node agent on duty was a Mac Mini. We configured the agent so that afterwards it was child’s play to recognize 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.