The desktop gap in enterprise testing | qventis blog

Walk through a bank, an insurer, a hospital or a manufacturer and count the screens. Some are web apps. Many are not. Claims handlers work in thick clients built fifteen years ago. Traders use custom Windows apps with dense, custom-drawn grids. Plant supervisors run packaged ERP clients. Call centers switch between a terminal emulator and a desktop CRM, often delivered over a remote desktop session.

These are frequently the most important systems in the business. They are also, very often, the least automated. Test automation has grown up around the browser, and the desktop has been left with fewer tools every year.

Why desktop testing is hard

Web automation works because browsers expose a structured page. Every element has a place in the DOM, and tools can find it by its attributes. Desktop apps offer no such guarantee.

• Incomplete accessibility trees. Windows UI automation relies on what each app chooses to expose. Older apps and some frameworks expose little or nothing useful.
• Custom-drawn controls. Grids, charts, schedulers and canvases are often painted as pixels. To an automation API, a whole trading blotter can appear as one blank control.
• Remote delivery. Apps streamed through remote desktop or virtual app platforms arrive as images. There is no element tree to inspect at all.
• Timing and state. Desktop apps keep long-lived state, open modal windows and process work in the background, which makes waits and recovery harder to get right.

Coordinate-based scripts and image matching have filled some of the gap, but they break with a resolution change, a theme update or a moved panel. Teams learn to distrust them, and the manual regression pack grows instead.

The tooling is thinning out

Two developments make this more pressing for Microsoft-centric shops.

First, WinAppDriver, the Windows Application Driver that many teams used to drive desktop apps through a WebDriver-style interface, is no longer actively maintained. Suites built on it still run, but they sit on a foundation that is not keeping pace with Windows and app frameworks.

Second, Microsoft has said that support for the Regression Suite Automation Tool (RSAT), used by many Dynamics 365 Finance and Operations teams for regression testing, ends on 15 May 2027. Teams that rely on RSAT for update testing have roughly seven months to decide what replaces it, and packaged-app updates do not wait.

Neither change is a crisis on its own. Together they mean that a lot of enterprise desktop regression testing needs a new home in the next year.

AI has barely arrived here

Generative AI has changed how many teams write web tests. The desktop and packaged-app world has seen far less of it. The World Quality Report from Capgemini puts the use of generative AI in ERP testing at about 6%. The same report found that, across all kinds of testing, only 33% of test cases are automated on average.

There are good reasons for the lag. Most AI test tools assume a browser and a DOM. Packaged apps come with complex business rules, regulated data and long upgrade cycles. And the people who know these apps best are often business experts, who need a way to describe tests without writing code.

What good desktop automation looks like

If you are evaluating options for desktop and packaged apps, these are the capabilities worth testing for, on your own app rather than a sample.

• Recognition by what is visible. Controls should be found the way a person finds them, by label and role, using vision where the accessibility tree falls short and using the tree where it is reliable.
• An object repository. Every control the tests use should live in one place, so a UI change is fixed once rather than in every script.
• Live recording that keeps up. Recording a flow should produce readable steps as you click, so business experts can capture a process in the time it takes to perform it.
• Deterministic replay. A run should take the same actions every time, with evidence for each step: screenshots, values read and timings.
• Heals as proposals. When a control changes, the tool should propose a fix with evidence and wait for a person to approve it.
• One language across channels. The steps for a desktop flow should read the same way as those for web and API flows, so one team can own an end-to-end process.

A desktop step written this way looks no different from a web step:

The third step acts on a cell inside a custom grid. The person writing it does not need to know how the grid is drawn.

Plan for 2027 now

A practical plan for the next two quarters:

• Inventory your desktop and packaged apps. Include thick clients, terminal apps and anything delivered over remote desktop. Note who owns each one and how often it changes.
• Find your dependencies. Identify suites that rely on WinAppDriver, RSAT or coordinate-based scripts, and how many tests each one holds.
• Rank by business risk. Start with the flows where a defect costs the most, such as financial postings, claims decisions and order fulfillment.
• Pilot on your hardest screen. Pick the custom grid or legacy dialog that has defeated tools before. If a candidate tool handles it, the easier screens will follow.
• Insist on portability. Whatever you choose, make sure tests are stored in a readable, version-controlled form you can take with you.

The systems that are hardest to automate are often the ones where an escaped defect costs the most.

The desktop gap is real, but it is closing for teams that plan for it. The 2027 deadlines are a useful forcing function to revisit apps that were written off as too hard to automate.

The Qventis Engine, the core of Qventis One, is built for this gap. It recognizes custom-drawn controls with vision, keeps an object repository, and its live recorder turns each click into a readable step as you work. Packs for SAP, Salesforce, Oracle and Workday bring the same plain English to packaged apps. Book a demo and bring your hardest screen.