Automated testing of desktop applications: manually, scheduled or in the build

Test automation

Every new version can break what worked yesterday. With desktop software, this often only shows up at the customer’s site: a dialog no longer opens, a command calculates incorrectly, an add-in fails to load. If you check everything by hand, you can hardly keep up when releases come in short intervals.

Automated UI tests operate your application like a user and check the result. What matters, however, is not only how you create the tests, but also when they run.

Which tests are worth automating

Automate what is repeated often first: regression tests after every change, large numbers of similar checks and data-driven tests, meaning the same workflow with many data sets. Checks with high accuracy requirements also belong here. Usability cannot be automated: whether a user interface is easy to understand has to be judged by a person.

Creating tests: record instead of programming

With our tool TesteriX, you record user actions without writing test code. During recording, TesteriX recognises the controls of the target application – menus, ribbons, dialogs, toolbars and input fields – and frames them as soon as the mouse moves over them. Every click and every input is saved as an action together with its target object. For recognition, TesteriX uses FlaUI, image processing and AI-based recognition. We use it for desktop applications built with WPF, WinForms, MFC or QML.

You then add checks: an action compares the actual value with the expected one. Return values are stored in variables and reused in later steps.

CAD systems need special treatment. Clicks in the drawing area depend on screen resolution and program version. For AutoCAD and BricsCAD, TesteriX therefore controls the drawing area through CAD commands from a catalogue of several hundred commands, for example “circle with centre 0,0,0 and radius 50”. Query commands then check what is actually in the drawing.

When the tests run

When running tests manually, your selection determines what is played back: one action, one test case or several test projects. F5 runs the test with debugging and stops at breakpoints and on errors. Ctrl+F5 runs it without interruption. F10 executes exactly one step – useful for narrowing down an error.

For the build, you save the solution as a .tse file and check it into the Git repository of the software under test. On the build server, the TesteriX TestPlayer, a variant without a graphical user interface, plays back the tests and passes the results to the CI server. This way the tests run with every build, for example in Azure DevOps, GitHub Actions or Jenkins. A scheduled build on the same server can take care of the nightly run.

Evaluating the results

After the run, the results window shows a status for every action: successful, warning, error or not executed. A warning reports, for example, conspicuous performance or values that were not compared. For every element, TesteriX records date, time and duration. As a report, you create a PDF for archiving or an HTML page for a quick review. Alternatively, you transfer the results to Xray in Jira. Screenshots of the actions can be included on request.

Reusing tests across versions

Tests for two program versions often differ only slightly. Instead of recording everything again, you insert a test case into the second project as a link. The link shows the steps of the original without copying them. If you change only a value there, the reference remains. Additions to the original are applied with “Synchronise link”.

Typical mistakes

• Testing on a production machine. Automated tests remote-control programs and change files. Use a dedicated test machine and back up the drawings and data you use beforehand.
• Clicking into the drawing area. Clicks on screen coordinates fail with a different resolution or version. Use CAD commands in CAD systems.
• Recording without checking. A test that only clicks will only find crashes. Checks are what make it meaningful.
• Huge solutions. Several small solutions are better than one large one. They stay fast and easy to manage.
• Forgetting the virus scanner. A tool that remote-controls other programs can trigger warnings. Set up an exception beforehand.
• Ignoring red tests. If a test fails permanently, soon nobody pays attention to it. Fix the cause or adjust the test straight away.

Sources: TesteriX help (version 2026.7), chapters “Recording and playback”, “CAD specifics”, “Results”, “Reuse via links” and “Integration into continuous integration”; Cadida: Test automation.