Last updated July 29, 2016.
Open source testing frameworks enable developers and testers to test their mobile applications and websites. By supporting multiple languages to write tests as well as integrating into many different development environments, they make a developer’s job easier.
There is just one major piece missing when using these frameworks and that’s device management.
Let’s use Selenium as an example. Supporting all major browsers and many different types of development and testing environments, Selenium is a great tool to automate website testing. It can execute tests simultaneously through the Selenium Grid. However, there are a few problems with the way Selenium is set up to work on real mobile devices.
In order to set up the testing environment for Selenium, the Selenium apps (iPhone Driver or AndroidDriver) must be built and installed on the device. Once complete, the Selenium apps need to be opened and ready to execute the tests. In order to specify a device, a tester will have to use the IP address of the device’s Wi-Fi connection which often changes if the device is turned off and on.
This is where a device access management tool such as deviceConnect™ comes in handy. Choosing an available device is no longer a challenge – it’s simplified using a device lab. It also allows greater flexibility to share devices across the organization both for unit testing with development to functional testing with the QA organization by pooling devices into one easily accessible solution. Too many times devices are lost or locked up when moving between teams. Without device lab capabilities, open source frameworks effectively force organizations to purchase extra devices. This cost burden is only amplified if the organization has remote teams.
Another problem with using open source framework tests is the continual update of device details within the script. When writing a script, the tester will run a test on a device by hardcoding the IP address into the test. If the IP address changes, the test will fail. If another tester has a test running on that device, there is no way to know if the device is in use and to change the script if it is. This can cause both tests to fail.
With a device access management tool, a tester can choose a single available device from a pool of devices that match certain criteria. For example, a tester may want to run a test against any model of iPhone running iOS 7. With such a tool, the tester doesn’t have to search around and make sure that particularly mobile device is plugged in and turned on with the app launched. The tester simply allows the tool to choose the first available iPhone with iOS 7 installed. Once the tester starts the test and retains the device, the device is no longer available to be used until the test is over and the device is released. The mess of finding IP addresses and managing devices has become simple.
Another way device access management helps the tester is enabling them to monitor the test and interact with the device if necessary. Selenium doesn’t allow a tester to see the script executing and, if remote, a way to interact with the device to resolve any issues. Device access management tools such as the deviceViewer with deviceConnect let the user create a session with the device, then view and control the device as required. Launching the deviceViewer and connecting to a device will allow a tester to view a test while it’s running, making test creation and debugging that much easier.
The benefits of open source frameworks during automated mobile website and application testing are numerous. But, they miss a critical area – the ability to share and manage real devices. Adding a device lab like deviceConnect into the equation, and its device access management capabilities, solves these challenges and further simplifies the testing process.
Want to learn more? Check out our latest posts!
Don’t forget to download our eBook on Amazon, to stay ahead of the curve in 2017!