16 Oct Test automation solution for desktop app built on WPF platform with Java SWT controls

About Client

Our client is a leading provider of software license management solutions for engineering software applications. Their software tools track large numbers of expensive software licenses that have been purchased by the organization and helps administrators reduce the number of licenses purchased but not used. Their expertise in this area has been built over years of consulting with organizations about their license management problems and developing solutions for these issues. Their platform supports over 30 license managers including Flexnet, DSLS and Hasp, as well as thousands of CAD, GIS, CAM, PLM, electronics and automotive applications.

Our Responsibilities

Fleek QA team is engaged with the client and works as their in-house QA automation team for their license management platform project. We deal with manual and automation testing for their web apps and desktops apps.

Our client had a desktop app which was supposed to manage the different software licenses. The desktop app users can then take various actions on license files and extract the desired information and reports. Fleek QA were responsible for manual and automated testing of their desktop app.

Challenges We Faced

While working with this client, we faced many challenges. One of the challenges was how to automate the tests related to their desktop app as it was built on WPF platform with Java SWT controls.

We tried automating the desktop test cases using several open source tools like WinAppDriver, Winium and so on. But as most of the controls on the desktop app were Java SWT designed controls, those were not actually exposed to these automation tools. We had no control over the elements embedded inside their desktop app by means of using any control locator.

How We Solved

Our team were continuously looking for work-around or alternate ways to locate the elements on their desktop as we were not able to get the exposure of their Java SWT control elements using any of the Windows Automation tools.

Fortunately, we came across another open source tool called Sikuli. The highlight of Sikuli was that it did not required the internal framework of the application to access its elements and controls on the UI. Sikuli purely identified the elements by detecting the presence of elements graphically on the screen and application UI. For example, if we need to locate a Login button on the application, we would just take a screenshot of Login button from the application and feed it to Sikuli test framework. When we run our tests using Sikuli to find the Login button element, Sikuli would simply search the same screenshot element on the current screen and if it found it, it will just send a mouse click to that element.

The Results

We were able to create a complete testing suite and framework for our client which does not required to penetrate through their application framework to find the elements. The entire test suite executes smoothly and produces desired results. Thus, a happy client!