Upcoming Squish Feature: Remote Control of Test Devices

The ability to work with remote devices is one of Squish's core features. While extremely powerful, it does not come without its disadvantages. During interactive test script recording it requires interaction with both the Squish IDE and the AUT. Debugging a faulty test script also usually requires preview of the current AUT state. This can be tedious if they are running on different machines, and it can become especially difficult if both systems are not in the same physical location.

Common Problems in Existing Remote Control Tools

Many platforms support a variety of dedicated remote control tools that could be used alongside Squish to resolve that problem. However, these tools come with some problems of their own:

  • Interoperability. If the controlled and the controlling platform are radically different, it may be difficult to find software that works on both systems.
  • Squish compatibility. Both remote control applications and the Squish GUI Tester use artificial UI events for their operation. This can lead to unwanted interference between them.
  • Setup. A separate set of tools may require a lot of work to become operational. This may include purchasing the license(s), installation and configuration, network setup, etc. It may need to be redone each time a new test system is added.
  • Availability. If you are testing a multi-platform AUT, you will probably need remote access to various kinds of test systems. In case the chosen software does not support some of them, you may be forced to use a heterogeneous solution which includes separate pieces of software and is difficult to use and maintain. Some embedded and mobile platforms do not offer any remote control software at all.

In order to help in overcoming some of these problems and to speed-up development of tests, the upcoming Squish release will include a remote control feature specifically tailored for GUI testing.

An Android AUT controlled by Squish IDE

The feature is designed as a testing aid and requires a connection to a working AUT on the target system. The data required for its operation is embedded within regular Squish communication. This means that the remote control can be used with minimal setup effort. In most cases, it should be just one click away.


The comfort of working with a far-off device over the remote control is directly dependent on the available bandwidth. Despite the lossless compression used on the video stream, slow connections may prove insufficient for comfortable work. In such a case, you may opt for a loss-y compression of image data that requires less data to be transferred for the cost of some image distortion. The screenshots used for image search and verification are still sent using lossless compression - just as you're used to.

Remote control should be available on any platform supported by Squish. However, on some of the platforms it cannot be used without additional setup.

As far as we know, no currently available Wayland compositor offers features required for remote controlling the user session. We are currently working on a set of plugins for all popular compositors. In order to access remote systems using Wayland, a corresponding plugin will have to be installed and enabled.

Remote control of a Gnome shell Wayland desktop with the froglogic plugin


The ability to see and to control remote test systems will let you avoid the need to move between different physical test setups or to install and maintain additional software. It will always remain compatible with Squish, and it will make recording and inspection of tests on multiple target systems easier and faster. It will grant the test writers instant access to devices in remote locations and minimize the need for interaction with the physical controls of the device.


    The Qt Company acquired froglogic GmbH in order to bring the functionality of their market-leading automated testing suite of tools to our comprehensive quality assurance offering.