Improved Screenshot Verification, Qt for WebAssembly support and much more coming with Squish 7.2

We are thrilled to introduce Squish GUI Tester 7.2, the ultimate software quality assurance tool for automating cross-platform GUI application tests. Packed with exciting new features, this latest release is designed to elevate your automated testing efforts to new heights.

Read on to discover the latest enhancements in this version

Watch our Squish 7.2 release overview video

Here's a quick 5-minute video that will provide you with an overview of the highlight features coming with Squish 7.2.

Squish for Qt

Qt WebAssembly Support

The Qt for WebAssembly module/platform has been around for a while now and appears to attract more and more users that seek a way of verifying that their Qt-based application not only works on the desktop or embedded systems but also on the WebAssembly platform. In some cases applications may even be built specifically for the WebAssembly platform. 

Squish for Qt for WebAssembly supports instrumenting Qt-based applications running in the browser for Qt 6.4 and Qt 6.5. Once the instrumented AUT is being executed through a supported browser using the standard setup of Squish for Web it will appear as a dedicated application context in Squish.

We provide full support for recording and replay of interactions as well as the usual introspection capabilities known from automating Qt-based applications on other platforms. Since Qt for WebAssembly makes use of a technology called Shadow DOM to integrate into the browser the recently added support for Shadow DOM in Squish for Web can be beneficial for applications that interact with their surrounding website.

If you're interested in testing Qt for WebAssembly applications with Squish, we have a dedicated article that includes a helpful video tutorial showing how to make a Qt for WebAssembly application testable with Squish.


QtWayland and Weston extension packaged in Squish sources

The Wayland platform architecture limits access of applications to other application windows or the desktop as a whole. This impacts Squish's ability to grab screenshots of the whole desktop, move the AUT window on screen as well as emulating interactions on lower/native level.

We now include a QtWayland and Weston custom extension in our Squish source packages and simplified the building process by including it in the Squish buildsystem. This enhancement will be especially beneficial for Squish users who are utilizing embedded systems. Given the prevalence of Wayland in these systems this inclusion will greatly assist in their testing and automation processes. In addition to including the code itself the Squish documentation has been extended to provide all necessary information on how to install and use these extensions to gain access to desktop screenshots, emulate native clicks and keyboard input and so on.

Squish for Java

SWT Scale support

The Scale widget in SWT is a versatile component commonly found in traditional user interfaces, allowing users to select the playback position in videos and make visual input selections within a specific value range.

Example image of Scale widget in SWT:

scale widget in swt

However, Squish's support for this control was previously limited to click and drag operations, which could be imprecise and require exact values when replaying them.

Squish 7.2 introduces support for setting specific values on the SWT Scale control by using the setValue function that is, for example, also used for Scrollbar controls or spin boxes. The specified number will be directly passed to the Scale control, adjusting the value selected in the slider accordingly and allowing more precise control of the value from the test script.

Java Detection/Reporting improvement

Squish for Java now provides a more seamless experience by eliminating the need for users to manually specify the exact Java runtime used by the application under test. Previously, this requirement posed challenges as Squish for Java needed to align perfectly with the selected Java runtime, especially since certain components of Squish for Java work within the application process itself. The previous verification measures in place were unable to cover all possible combinations and did not have the capability to detect new architectures, such as Java runtimes for ARM-based systems.

To address these limitations, the detection logic in the Squish installer has undergone a complete overhaul. This revamp enables Squish to detect a wider range of incompatibilities and ensures its compatibility with future platforms. Additionally, we have improved the error reporting and messages to provide clear guidance to our users, helping them find the optimal solution to any setup issues they may encounter.

Scripting & Debugging tests


Screenshot comparisons in Squish are very versatile, they are based on the same object identification principles allowing to compare the rendered image of individual objects to a specific baseline image. The comparison process can be configured in many ways too, allowing to account for rendering differences in modern systems or dynamically changing parts. However the way Squish obtains the screenshot of the actual object is currently not configurable and rather dictated by the platform where the application runs, the Squish edition and possibly the object type.

Similar to the test.vpWithObject function a new function test.vpWithImage has been introduced. The function takes a screenshot verification point file to provide the expected image as well as any additional comparison configurations to allow for flexible comparison methods being used. For the actual image, representing the rendered image of the object to be compared against, a second parameter can be specified that can either be a file on disk in a common image format (png, jpg, bmp) or it can be an Image object as well. The test.vpWithImage function will compare the expected image stored in the verification point file with the actual image provided via the second argument using all the normal comparison options specified in the verification point. Reporting of failure or pass happens in the same way as the test.vp function.

Debugger introspection for application contexts

Squish provides access to some basic information about the applications being automated as part of the ApplicationContext object, for example the process identifier, the commandline that it was launched with or even a rough information about used memory. However this information was not easily exposed in the IDE, instead it had to be queried by evaluating script code in the IDE's Script Console. This can be quite cumbersome and it is inconsistent with other squish-specific types as well.

Squish 7.2 makes the different properties of the ApplicationContext object available within the Variables view of the Squish IDE. This means, any script variable that refers to an ApplicationContext object can be expanded in the variables view and all the properties and the values of the properties are being shown. So it is a lot easier to interactively debug a test script now and observe for example the use of the memory in the application at different points. This feature is currently limited to the Python and Javascript languages, we plan to add support for the other scripting languages in a future release.

Show in Application Objects

Finding good object names for writing test automation scripts can be quite a challenge. The name needs to be specific enough to identify the right object, but somewhat generic at the same time so the object is also found when small changes are made in the application UI or when the UI of the application changes dynamically - for example including a filename in the window title. Squish already has features that help with this task, for example you can use the Check Existence button in the Object Map editor to verify that a modified object name still finds an object. However finding an object with the given name does not necessarily mean it is also the correct object, checking this so far required running a test or using the builtin script console.

A new button, labelled Show in Application Objects, has been introduced into the Object Map editor. Activating this button will cause the IDE to look up the selected object name in all running and hooked application(s). When finding an object with that name the object will be shown in the Application Objects View. The Application Objects view allows to inspect the object in the same way as if the object had been picked by the user. The user can use all common features from the AUT inspection for the found object, for example highlight the object in the application window or inspect individual property values in the Properties view.

The object map does not need to be saved before using this feature, so it is very easy to experiment with different modifications to the object name properties without breaking the object map file. This new feature is intended to accelerate the process of modifying object names to better fit the dynamic application behavior or expected changes within the UI, as it does not require to run a test script to test changes in the object name.

Quality of Life improvements

JUnit report including skipped testcases

Squish allows to indicate that tests or parts of them where skipped by different means, including commandline options, the test.skip script function or implicit behavior in BDD. This information can be useful when analysing test results. Squish includes details about skipped steps, testcases and sections in its main XML3 report format since the introduction of BDD already. The JUnit report was so far lacking this information, leading to a gap when integrating Squish test results with tools that are based on the JUnit format. This has been improved now, the JUnit format generates the <skipped> element including a corresponding message, if available, detailing why the test case, section, or step has been skipped.

Browser Detection

The detection logic in Squish for Web has been extended to consider the users selected default browser on different operating systems instead of picking a default browser based on the platform and version. This change intends to improve the default selection for new users, while still keeping the configurability necessary to run Squish tests with different browsers. This also ensures that the browser, a user is using most of the time, and hence most likely keeping up to date, is the one he first uses Squish with.

Improved offline documentation

The Squish team switched the system for managing its documentation from the docbook format to the qdoc format a while ago. For technical reasons this meant a small step backwards for the generated HTML documentation that is included in the Squish binary packages. The overall look was not the same as the version available online and there was no search available anymore. These two points have now been fixed, the styling of the offline documentation follows that of the online version and there is a search feature integrated which is working locally without the need to be connected to the internet in any way.

Download and Free Trial


For existing users and evaluators new packages for Squish 7.2 are now available in the Qt customer portal.


Free Trial

If you are new to Squish we offer a fully supported 10-day free trial.

Fill out the form below and you will receive your own Squish evaluation copy soon.