Blog

Desktop Automation Testing Tools: A Decision Framework for QA Teams

by Rajesh K | Aug 23, 2026 | Desktop App Automation Testing, Blog, Latest Post | 0 comments

Choosing the right desktop automation testing tools is a critical decision for any QA team. A poor choice leads to flaky tests, high maintenance costs, and unreliable CI/CD pipelines. Yet, with dozens of options available, making the right choice can feel overwhelming. This guide provides a practical, step-by-step framework for evaluating desktop automation testing tool. Whether you’re automating WPF, WinForms, or cross-platform desktop applications, this framework will help you identify the right tool for your environment. If you need expert guidance, Codoid’s desktop app automation testing services can help you select the right tools and build a maintainable automation strategy.

Key Takeaways

• Start with application technology and object recognition, not vendor feature lists.
• Treat unsupported controls, operating systems, security restrictions, and CI execution constraints as hard gates.
• Prefer object- or accessibility-based automation over coordinate-based interactions for maintainable regression suites.
• Run a proof of concept against difficult controls, not only login forms and standard buttons.
• Measure stability, locator quality, execution time, diagnostic quality, and maintenance effort during the evaluation.
• Use a weighted scorecard only after every candidate has passed the mandatory requirements.
• Consider framework health and product lifecycle. In particular, Appium’s Windows driver currently warns that Microsoft’s WinAppDriver server has not been maintained for years.

Choose a desktop automation testing tool by first eliminating tools that cannot reliably recognize your application’s UI technology, controls, operating systems, or execution environment. Then compare the remaining candidates using weighted criteria such as locator stability, maintainability, CI/CD execution, team skills, debugging, support, and total cost of ownership.

The best tool is not the one with the longest feature list. It is the tool that can reliably automate your application’s critical controls in your real test environment with an acceptable long-term maintenance cost.

• What Is a Desktop Application Automation Testing Tool?
• Why Does Choosing the Right Desktop Automation Tool Matter?
• How Does Desktop Application Automation Work?
• Step-by-Step Tool Selection Framework
• A Weighted Decision Framework
• Practical Example: Selecting a Tool
• Desktop Automation Tool Approaches Compared
• Current Desktop Automation Tool Options
• Best Practices for Selecting a Tool
• Common Mistakes When Choosing a Tool
• Troubleshooting Tool Evaluations
• Limitations and Risks of Desktop UI Automation

A desktop application automation testing tool is software that programmatically controls and verifies applications installed and executed on a desktop operating system.

Depending on the tool and application technology, it may identify UI elements through:

• Microsoft UI Automation (UIA)
• Native Windows APIs
• Framework-specific object models
• Accessibility APIs
• Java, Qt, WPF, WinForms, or other technology-specific adapters
• Image recognition or OCR
• Screen coordinates as a fallback

For Windows applications, Microsoft UI Automation is particularly important. Microsoft describes UI Automation as an accessibility framework that exposes desktop UI elements programmatically and explicitly supports interaction from automated test scripts.

Desktop UI automation is different from API or unit testing. An API test validates application interfaces without manipulating the visible desktop UI, whereas a desktop automation test usually launches the real application, finds windows and controls, performs user actions, and verifies the resulting state.

It is also different from browser automation. Selenium-style browser testing primarily operates against a browser’s DOM and WebDriver interfaces. Native desktop applications may instead contain Win32 controls, WPF trees, Java components, Qt widgets, custom-rendered grids, embedded browsers, or several technologies in the same process.

That difference is why tool selection matters so much. Codoid’s expertise in desktop apps automation testing covers the full spectrum of these technologies.

A poor desktop automation tool choice creates problems that may not appear during the first demonstration.

A recorder may successfully automate a login screen yet fail when the suite reaches:

• Virtualized data grids
• Owner-drawn controls
• Custom WPF components
• Embedded Chromium content
• Native dialogs launched in separate processes
• Windows security prompts
• Drag-and-drop operations
• Applications running with elevated privileges
• Remote execution agents
• Legacy controls with incomplete accessibility metadata

When the tool cannot understand these controls structurally, teams often compensate with coordinates, screenshots, fixed delays, or increasingly complex locator expressions.

The result is usually higher maintenance.

Object-level recognition therefore deserves more weight than recording convenience. SmartBear’s TestComplete documentation, for example, distinguishes coordinate-based black-box interaction from technology modules that expose application objects and controls. Its documentation also notes that robust GUI automation relies on identifying individual UI objects and their properties rather than simply clicking screen coordinates.

The selection decision also affects CI infrastructure. Desktop GUI tests frequently need a usable graphical session rather than a conventional headless build worker. TestComplete, for example, documents that GUI tests simulating user actions cannot execute while the Windows computer is locked because the user session is frozen.

A tool that looks inexpensive in isolation can therefore become expensive once VM capacity, licenses, test maintenance, failed reruns, and specialized engineering effort are included.

Although implementations vary, most object-based desktop automation follows the same process:

• Launch or attach to the application under test.
• Inspect the application’s UI hierarchy.
• Locate a control using properties such as Automation ID, name, class, control type, hierarchy, or framework-specific attributes.
• Perform an interaction, such as clicking a button or entering text.
• Wait for the resulting state rather than assuming an arbitrary timing interval.
• Read application state or control properties.
• Assert the expected result.
• Capture diagnostics such as logs, screenshots, object information, or traces if the test fails.
• Reset application state before the next test.

Codoid’s guide on automating desktop applications using C# provides a practical implementation of this workflow.

1. Inventory the Application’s Real Technology Stack

Do not begin by comparing tools. Begin by identifying what must be automated.

Document:

• Operating system and supported OS versions
• Application framework
• Runtime version
• 32-bit or 64-bit architecture
• Standard versus custom controls
• Third-party component libraries
• Embedded browser components
• Child processes
• Native dialogs
• Privilege requirements
• Remote desktop or virtualized environments
• Required localization and DPI configurations

A Windows desktop product described simply as “.NET” may actually contain WPF windows, WinForms legacy dialogs, a DevExpress grid, a CEF-based embedded page, and native Windows file dialogs.

Those distinctions can determine whether a tool succeeds.

Current commercial tools illustrate this technology-specific approach. Ranorex documents separate plugins for WPF, WinForms, Qt, Java, CEF, UI Automation, MSA, and other desktop technologies. Its guidance specifically recommends considering whether the application mixes frameworks and whether it contains custom or third-party controls.

Expected result: a technology inventory against which every candidate can be evaluated.

2. Define Hard-Gate Requirements

A hard gate is a requirement a candidate must satisfy regardless of its score elsewhere.

Typical gates include:

A candidate that fails a genuine mandatory requirement should normally be removed rather than compensated with points from unrelated features.

For example, excellent reporting cannot compensate for an inability to select rows reliably in the application’s primary transaction grid.

3. Inspect the Application’s Accessibility and Object Tree

Install the candidate’s inspector or compatible accessibility inspection tooling and examine the application before building an entire suite.

Ask:

• Are important controls visible?
• Do controls expose unique IDs?
• Are names generated dynamically?
• Can individual grid cells be addressed?
• Are off-screen or virtualized elements discoverable?
• Can menus and pop-ups be inspected?
• Are controls split into meaningful child elements?
• Does object identity remain stable after restarting the application?
• What happens after upgrading the UI framework?

For Microsoft UI Automation-based solutions, determine whether the application’s controls expose appropriate UIA information and patterns. Microsoft UI Automation exists precisely to provide programmatic information and interaction capabilities for desktop interfaces.

This inspection often eliminates unsuitable tools faster than creating recorded scripts.

4. Evaluate Locator Quality Before Recording Convenience

A desktop testing tool should make it possible to create locators that are:

• Unique
• Stable
• Readable
• Independent of screen position
• Minimally dependent on deep UI hierarchy
• Resistant to cosmetic layout changes

Consider this locator:

    Window[2]/Pane[1]/Pane[3]/Button[4]
    

It may be unique today but fragile if another pane is inserted.

A more maintainable locator might use:

    AutomationId = "SubmitInvoice"
    ControlType = "Button"
    

FlaUI, for example, is a .NET UI automation library built around Microsoft’s UI Automation technologies, including UIA2 and UIA3. Its project documentation discusses the differences between these UI Automation interfaces.

Commercial products may add framework-specific recognition beyond generic accessibility APIs. Ranorex, for instance, documents that its WPF plugin can expose framework-specific properties and complex controls, while its UIA plugin provides broader standardized Windows UI coverage.

The correct question is therefore not:

“Does the tool support object recognition?”

It is:

“Does the tool expose stable properties for the controls that matter in our application?”

5. Test the Hardest Controls First

A proof of concept should be designed to fail quickly if the tool is unsuitable.

Do not spend most of the pilot automating:

• Login fields
• Basic buttons
• Static labels
• Standard menus

Instead, include:

• The most complex data grid.
• A custom control.
• A dynamically generated dialog.
• An embedded component.
• A workflow involving multiple windows.
• A long-running asynchronous operation.
• File upload or save dialogs if relevant.
• A test that requires application restart or process recovery.
• A scenario using the real CI execution environment.
• One deliberately failing test to assess diagnostics.

If these scenarios work reliably, routine controls are less likely to determine the selection.

6. Evaluate Synchronization and Timing Behavior

Desktop applications are asynchronous.

A click may trigger:

• Database access
• Background calculations
• Window creation
• UI virtualization
• Network requests
• Rendering
• Worker threads

Tests should therefore synchronize against observable conditions rather than relying heavily on:

    Sleep(5000)
    

Evaluate whether the tool provides practical mechanisms for:

• Waiting until elements exist
• Waiting until windows become active
• Waiting until controls are enabled
• Polling application state
• Configurable timeouts
• Retrying transient element lookup
• Waiting for processes
• Handling modal dialogs

A tool that makes synchronization difficult can produce a suite that is stable on a developer workstation but unreliable in shared test infrastructure.

7. Verify CI/CD and Remote Execution Early

Do not assume a desktop test can run like a headless API suite.

Verify:

• How the Windows session is created
• Whether the screen may be locked
• Whether RDP disconnection changes execution
• Required screen resolution
• Required DPI scaling
• Service-account behavior
• Administrator privileges
• Test-agent installation
• License availability
• Parallel execution model
• VM provisioning and cleanup
• Artifact collection after failure

The practical question is:

Can the same test that passes on a developer machine run repeatedly in the intended build infrastructure without manual intervention?

Some products provide explicit remote execution mechanisms. Squish, for example, separates squishrunner from squishserver and supports execution against a server on another machine through its command-line tooling.

For practical guidance on handling RDP-related execution issues, see Codoid’s article on fixing RDP minimized test failures.

8. Measure Maintainability, Not Just Initial Scripting Speed

Record-and-playback can accelerate initial test creation, but initial creation is only one part of lifecycle cost.

Measure what happens when:

• A button is moved
• A dialog gains another panel
• A control name changes
• A grid library is upgraded
• The application startup sequence changes
• A new Windows version is introduced
• A shared component is redesigned

Evaluate whether the tool supports:

• Centralized object repositories or page/screen objects
• Reusable components
• Functions and libraries
• Parameterized tests
• Source control
• Code review
• Refactoring
• Shared locator definitions
• Custom waits
• Test data management

The relevant metric is not “minutes to record a test.”

9. Match the Authoring Model to the Team

Desktop automation platforms fall broadly into three authoring models:

For a .NET engineering organization, a C# library such as FlaUI may integrate naturally with existing coding practices. Codoid’s Reqnroll tutorial for building a desktop automation framework with FlaUI & NUnit is an excellent starting point.

For Python-heavy QA teams, pywinauto provides Windows automation through Win32 and Microsoft UI Automation backends. Its documentation recommends selecting the backend according to the technology used by the application. Codoid’s guide on desktop app automation using Python covers this approach.

For organizations that need an integrated IDE, object repository, recorder, reporting, and vendor support, commercial platforms may reduce the amount of framework engineering required.

Tool selection should follow team capabilities rather than forcing the team into an unsuitable operating model.

10. Calculate Total Cost of Ownership

License price is only one component.

Use:

    Annual TCO = Tool licenses
                 + Execution licenses
                 + Test infrastructure
                 + Framework development
                 + Test maintenance
                 + Failure investigation
                 + Training
                 + Upgrade validation
                 + Support overhead
    

An open-source framework has a license cost of zero but not necessarily a lower total cost.

Similarly, a commercial product may cost more upfront while reducing the engineering required for object inspection, reporting, technology-specific support, and troubleshooting.

Calculate cost against your actual staffing and execution model.

Once candidates pass the hard gates, score them using the same proof-of-concept evidence.

A useful starting model is:

Score each criterion from 1 to 5:

• 1: unacceptable
• 2: major weaknesses
• 3: acceptable with limitations
• 4: strong
• 5: excellent for the specific application

Calculate:

    Weighted score = Σ (criterion score × 5 × criterion weight)
    

A candidate scoring 89/100 is not automatically better than one scoring 84/100 if the first candidate failed a mandatory control-automation requirement.

Hard gates come first. Weighted scores come second.

Adjust the weights to match the project’s risks. A regulated enterprise application might assign more weight to vendor support and auditability. A small engineering team automating an internal .NET tool might place more weight on code integration and cost.

Consider a fictional QA team automating an order-management client.

Application

• Windows 11
• WPF/.NET desktop application
• Third-party data grids
• Several modal dialogs
• Approximately 150 regression scenarios
• C# engineering organization
• Tests run nightly on Windows VMs
• CI pipeline triggers smoke tests for release candidates

Mandatory Requirements

The team defines four hard gates:

• Reliable WPF object recognition.
• Stable access to rows and cells in the primary data grid.
• C#-friendly extensibility.
• Unattended execution in the approved VM environment.

The team then selects three candidates for a pilot.

Pilot Scenarios

Each candidate automates the same ten workflows:

• Login
• Search order
• Edit a grid cell
• Sort the grid
• Open a contextual menu
• Add an order
• Handle a validation dialog
• Export a file
• Restart the application
• Recover from an intentional validation failure

The team executes every scenario repeatedly from the same VM image.

Example Scorecard

The following scores are illustrative, not rankings of real products:

The team should also record evidence such as:

• Percentage of critical controls that have semantic locators
• Number of coordinate or image-based fallbacks
• Failures across repeated identical runs
• Median runtime
• Investigation time for an intentional failure
• Lines of custom helper code
• Time required to modify a test after a UI change

Suppose Tool B receives a respectable weighted score but cannot reliably address individual cells in the application’s primary grid. Because grid automation was defined as a hard gate, Tool B should be eliminated rather than rescued by good reporting or execution features.

That is the central advantage of a decision framework: a business-critical limitation cannot disappear inside an average.

No category wins universally.

The application’s object model and the team’s operating constraints determine which architecture is appropriate.

The following list is a shortlist, not a universal ranking.

FlaUI

FlaUI is an open-source .NET library for Windows UI automation. It supports Microsoft’s UI Automation interfaces and is particularly relevant to C#/.NET test engineering teams. FlaUI 5.0 added .NET 8 support.

Consider FlaUI when:

• The application is Windows-based.
• Your team prefers C#/.NET.
• You want a code-first framework.
• UI Automation exposes the required controls reliably.
• Your team can build reporting, test architecture, and execution infrastructure around the library.

Validate carefully: custom controls, complex WinForms/UIA differences, CI desktop-session behavior, and project release cadence.

Codoid’s Reqnroll tutorial with FlaUI & NUnit provides a practical implementation guide.

pywinauto

pywinauto is a Python-based Windows GUI automation framework. Its documented Windows backends include win32 for legacy/native controls and uia for Microsoft UI Automation, including technologies such as WPF and WinForms.

Consider pywinauto when:

• The team is Python-oriented.
• The target is Windows.
• Win32 or UIA exposes the relevant application controls.
• A lightweight code-first library is preferable to a complete commercial IDE.

Validate carefully: the specific control library, project maintenance requirements, synchronization behavior, and long-term support expectations.

For a Python-based approach, see Codoid’s guide on desktop app automation using Python.

Ranorex Studio

Ranorex Studio provides Windows desktop automation with technology-specific plugins covering areas such as WPF, WinForms, Java, Qt, UIA, MSAA, CEF, and other application technologies. Its July 29, 2026 release information documents continued updates to Windows Forms and WPF control recognition.

Consider Ranorex when:

• The application mixes desktop UI technologies.
• Built-in inspection and recording are important.
• Both coded and lower-code workflows are useful.
• Technology-specific object recognition is a high priority.
• Commercial support is justified by the project.

TestComplete

SmartBear TestComplete provides a Windows desktop testing platform with support for technologies including .NET, WPF, C++, Java, JavaFX, Delphi, Qt, and others. Its current TestComplete 15.83 documentation includes support for .NET 5 through .NET 10 as well as .NET Framework applications.

It also provides object-level control recognition, recording, checkpoints, and an integrated testing environment.

Consider TestComplete when:

• Windows desktop technology breadth is required.
• Teams value an integrated IDE and recorder.
• Object repositories and packaged reporting are desirable.
• The organization prefers commercial tooling.

Validate carefully: every embedded framework and third-party component against the current support matrix rather than assuming that broad “desktop” support covers all versions.

For practical TestComplete tips, see Codoid’s guide on implementing BDD for desktop app automation with TestComplete.

Squish

Squish 9.2 supports automated GUI testing across Windows, Linux, macOS, Android, and iOS and includes support for native and cross-platform GUI technologies such as Qt, Java, and Tk. Its documentation states that it identifies GUI objects through properties rather than screen coordinates.

Consider Squish when:

• The same desktop product runs on multiple operating systems.
• Qt is a major part of the application.
• Remote execution is needed.
• Property-based GUI object identification is required across platforms.

Squish is especially relevant when “desktop” means more than Windows.

OpenText Functional Testing

OpenText Functional Testing 26.3 provides add-ins for .NET, WPF, Java, Qt, UI Automation, SAP, Oracle, PowerBuilder and other enterprise technologies. Its current support matrix includes Windows 11 and Windows Server environments and lists .NET and WPF support through current .NET generations.

Its GUI testing model includes test objects, checkpoints, parameterization, reusable function libraries, and keyword-driven testing.

Consider it when:

• The organization has a large enterprise application portfolio.
• Specialized enterprise add-ins matter.
• Centralized commercial support is required.
• Existing OpenText testing infrastructure can be reused.

Appium Windows Driver

Appium’s Windows Driver supplies an Appium-compatible interface for Windows automation and supports application types including UWP, WinForms, WPF, and Win32 through Microsoft’s WinAppDriver server.

However, this option carries an important architectural consideration in 2026: the Appium Windows Driver documentation explicitly warns that Microsoft’s WinAppDriver server has not been maintained for years and suggests considering alternatives such as NovaWindows Driver. Microsoft’s WinAppDriver release page still identifies version 1.2.1 as its latest stable release.

Therefore, teams should not select Appium Windows automation solely because they already use Appium for mobile testing.

Treat driver lifecycle and Windows-version compatibility as part of the proof of concept. Codoid’s WinAppDriver for Desktop Automation Testing Guide provides detailed setup and usage instructions.

GYRA

GYRA is Codoid’s free desktop application automation testing tool developed to overcome challenges and limitations present in other tools. It supports Windows 8 to 11 and offers a reliable alternative for teams facing compatibility issues. Learn more about GYRA.

Test Application-Specific Controls Before Buying or Standardizing

A generic vendor demonstration cannot establish compatibility with your custom grid, embedded component, or security configuration.

Prefer Stable Semantic Locators

Use automation IDs, object properties, control types, or framework-specific identifiers when possible. Limit coordinates and image matching to cases where structural automation is genuinely unavailable.

Ask Developers to Improve Testability

Automation quality is partly an application-design issue.

Where practical, developers can provide:

• Stable Automation IDs
• Accessible names
• Correct UI Automation patterns
• Predictable dialog identifiers
• Test-friendly startup options
• APIs for creating test data

Improving the application’s automation surface can deliver more value than continuously engineering around poor locators.

Separate UI Coverage from Lower-Level Testing

Do not automate every possible validation through the desktop UI.

Keep broad business-critical workflows in the GUI suite while pushing suitable validation into:

• Unit tests
• Component tests
• API tests
• Service-level integration tests

This reduces the number of slow and environment-sensitive desktop scenarios.

Establish Locator Standards Before Scaling

Define which properties are preferred, which fallback techniques are allowed, and how objects should be centralized.

Measure Flakiness

A test that fails intermittently without a product defect creates operational cost.

Track:

    Non-product automation failures × 100
    Total automated executions
    

Classify failures rather than simply rerunning them until green.

Version the Test Environment

Record:

• Windows build
• Application version
• Tool version
• Driver version
• Runtime versions
• UI library versions
• Display settings

This makes automation failures reproducible.

Why can the tool see the window but not its controls?

The likely cause is that the application’s controls are custom rendered, use an unsupported framework, or do not expose usable accessibility information.

First inspect the control with the tool’s object inspector and, on Windows, compare what Microsoft UI Automation exposes. Then determine whether a framework-specific plugin or application-side accessibility change is required.

Avoid solving the problem immediately with screen coordinates because doing so can conceal a fundamental compatibility limitation.

Why do tests pass locally but fail on the CI machine?

Check the execution environment before changing the test.

Compare:

• Windows version
• Tool and driver versions
• Application privileges
• User session state
• Screen resolution
• DPI scaling
• Fonts and localization
• Application configuration
• Network dependencies
• Available CPU and memory

Desktop GUI automation can depend on an interactive graphical session. For example, TestComplete documents that GUI tests requiring user interaction cannot execute on a locked Windows computer.

Why does the automation tool select the wrong control?

The locator is probably not unique enough.

Inspect the matching elements and add stable semantic properties such as:

• Automation ID
• Control type
• Meaningful parent container
• Stable application-specific property

Do not immediately add the entire absolute hierarchy. Extremely long hierarchical selectors can exchange one form of fragility for another.

Why does the suite become unreliable as it grows?

Common causes include:

• Fixed sleeps
• Shared application state
• Locator duplication
• Test-order dependencies
• Accumulated dialogs
• Incomplete cleanup
• Environment contention
• Inconsistent abstraction layers

The solution is generally architectural rather than a larger timeout.

Centralize synchronization, reset state explicitly, separate reusable screen objects from test intent, and classify flaky failures.

Desktop automation has inherent constraints that a tool cannot eliminate completely.

GUI Execution Is Environment-Sensitive

Resolution, session state, permissions, foreground windows, operating-system behavior, and application rendering can affect execution.

Custom Controls May Require Special Handling

Generic UI Automation may not expose enough information. Framework-specific plugins, accessibility improvements, or custom test hooks may be necessary.

UI Suites Are Relatively Expensive

Desktop end-to-end tests typically execute more slowly and require more infrastructure than unit or API tests.

Tool Support Changes

Operating systems, .NET versions, Java runtimes, Qt versions, Chromium components, and commercial products all evolve.

A compatibility decision made today must therefore be revisited during significant platform upgrades.

Open-Source Dependencies Introduce Lifecycle Risk

Open source can provide excellent technical solutions, but the team adopting a library also accepts responsibility for evaluating maintenance activity, unresolved issues, release cadence, and internal ability to troubleshoot it.

Commercial Tooling Does Not Remove Engineering Work

Recorders and object repositories can accelerate automation, but maintainable test design, state management, synchronization, CI architecture, and coverage strategy still require engineering discipline.

Choosing a desktop automation testing tool should be an engineering decision, not a feature-comparison exercise. Begin with the application itself: identify its operating systems, UI frameworks, custom controls, accessibility characteristics, privilege model, and execution environment. Turn mandatory requirements into hard gates and eliminate candidates that cannot satisfy them. Then run the remaining tools against the application’s most difficult workflows. Measure object recognition, locator stability, synchronization, repeated-run reliability, CI behavior, diagnostics, maintainability, team fit, lifecycle risk, and total cost. Only after that evidence exists should a weighted scorecard determine the preferred option.

The resulting decision may be a lightweight code-first library, a commercial desktop automation platform, an Appium-compatible architecture, or a cross-platform GUI tool. What matters is not which tool is most popular. The right desktop automation tool is the one that makes your application’s critical workflows reliably automatable, diagnosable, and maintainable in the environment where the suite will actually run.

Need Help Choosing the Right Desktop Automation Tool?

Talk to a Desktop Automation Expert

Frequently Asked Questions

Reqnroll Tutorial: Build a Desktop Automation Framework with FlaUI & NUnit (C#)

by Rajesh K | Aug 12, 2026 | Desktop App Automation Testing, Blog, Latest Post | 0 comments

In this Reqnroll tutorial, you’ll build a Windows Desktop Automation framework using FlaUI, a modern, open-source .NET library for automating Windows desktop applications. It is built on top of Microsoft’s native UI Automation (UIA) framework and acts as a lightweight wrapper it simplifies day-to-day interaction with UI elements, while still giving you access to the underlying UI Automation APIs when you need advanced functionality.

FlaUI supports a wide range of Windows application technologies, including:

• Win32
• Windows Forms (WinForms)
• Windows Presentation Foundation (WPF)
• Universal Windows Platform (UWP)
• Windows Store applications

Looking to automate a real enterprise desktop application instead of Notepad? See how our desktop app automation testing services can help.

What Is FlaUI?

FlaUI is a free, open-source .NET library for automating Windows desktop applications (Win32, WinForms, WPF, and UWP) by wrapping Microsoft’s UI Automation API in a clean C# interface.

Why Choose FlaUI?

FlaUI stands out for its clean, modern API, its active community support, and its seamless integration with the .NET ecosystem. It works naturally with popular testing frameworks such as NUnit, Reqnroll, xUnit, and MSTest, which means teams can build scalable automation frameworks and plug them straight into CI/CD pipelines.

Unlike older desktop automation tools that rely on additional background services or complicated configuration, FlaUI talks directly to Microsoft’s UI Automation framework. The result is faster execution, better stability, and easier long-term maintenance.

What’s the Difference Between UIA2 and UIA3?

UIA2 is FlaUI’s managed .NET backend for older Win32/WinForms apps, while UIA3 is the newer COM-based backend with better support for WPF and UWP. Use UIA3 by default unless you’re automating a legacy Win32 application.

A unique advantage of FlaUI is that it supports both UIA2 and UIA3, so you can pick whichever automation backend best fits your target application:

• UIA2 (UI Automation Version 2) the managed .NET implementation of Microsoft’s UI Automation API. It offers strong compatibility with traditional Win32 and WinForms applications.
• UIA3 (UI Automation Version 3) the newer, COM-based implementation. It provides enhanced support for WPF, UWP, and other modern Windows applications, along with better compatibility with newer controls.

If you’ve automated web applications with Selenium or Playwright, you already understand the value of BDD (Behavior Driven Development) and Page Object Models. But desktop applications Notepad, calculators, WPF/WinForms line-of-business tools, legacy Win32 apps don’t have a DOM, and Selenium can’t touch them.

That’s where FlaUI comes in. Combined with Reqnroll (the actively maintained successor to SpecFlow) and NUnit, you get a production-grade framework for automating Windows desktop applications using plain-English Gherkin scenarios.

By the end of this article, you’ll have:

• A working Reqnroll + NUnit + FlaUI solution built from a blank Visual Studio project
• A feature file written in Gherkin
• A Page Object Model class wrapping Notepad
• Step definitions that map Gherkin steps to C# code
• Hooks that log every step and capture a screenshot on failure
• HTML test reports generated automatically
• The ability to run everything from the command line using the NUnit console runner
• The skills to troubleshoot failures and extend the framework confidently

We’ll use Notepad as the target application throughout this tutorial. It ships with every Windows machine, requires no installation, and is perfect for learning the mechanics of desktop automation without fighting with a complex UI.

Why Reqnroll, NUnit, and FlaUI Work Well Together

1. Prerequisites

Install the following before you start:

• Visual Studio Community Edition 2026 (or 2022 instructions are nearly identical) free from visualstudio.microsoft.com
• The .NET SDK (latest supported LTS version) verify with the command below
• NUnit Console Runner used later to execute tests from the command line. Install via NuGet or download from the NUnit documentation and releases page
• FlaUInspect a free inspection tool (similar to Selenium’s “Inspect Element”) that lets you see the AutomationId, Name, ControlType, and ClassName of every control in a desktop application. Download it from the FlaUI GitHub repository releases

dotnet --version

Tip for beginners: Open FlaUInspect, then open Notepad side by side. Click on Notepad’s text area or “File” menu inside FlaUInspect and note the AutomationId values. You’ll need these in Step 4 of this guide.

2. Install the Reqnroll Visual Studio Extension

The Reqnroll extension gives Visual Studio the ability to understand .feature files, provide syntax highlighting, and auto-generate step definition skeletons.

Steps:

• Open Visual Studio → Extensions menu → Manage Extensions
• In the search box, type “Reqnroll for Visual Studio 2022 & 2026”
• Select it from the results and click Install
• Restart Visual Studio when prompted to complete installation

Once installed, .feature files will render with proper Gherkin syntax highlighting, and right-clicking a scenario will give you options like “Generate Step Definitions.”

3. Create a Reqnroll NUnit Project

3.1 Create the project

• File → New → Project
• In the project template search box, type “Reqnroll”
• Select Reqnroll Project (NUnit) this scaffolds a project pre-wired for NUnit rather than MSTest or xUnit

3.2 Name your project

Give it a meaningful, lowercase-hyphenated or PascalCase name that reflects its purpose. For this tutorial we’ll use:

qa-test-flaui

3.3 Note the new solution format

Visual Studio 2026 creates solutions using the newer .slnx format (an XML-based replacement for the legacy .sln format). You’ll see:

qa-test-flaui.slnx

This is functionally equivalent to a .sln file all the same commands (dotnet build, dotnet test) work identically. You don’t need to change anything about your workflow.

3.4 Install the required NuGet packages

Open Tools → NuGet Package Manager → Manage NuGet Packages for Solution, or use the Package Manager Console / dotnet add package commands below.

i. Reqnroll packages (BDD framework + NUnit integration)

dotnet add package Reqnroll
dotnet add package Reqnroll.NUnit

ii. NUnit packages

dotnet add package NUnit
dotnet add package NUnit3TestAdapter
dotnet add package Microsoft.NET.Test.Sdk

• NUnit the core testing/assertion framework
• NUnit3TestAdapter required for Visual Studio’s Test Explorer to discover and run your tests
• Microsoft.NET.Test.Sdk the general .NET test SDK required by any test project

iii. FlaUI packages

dotnet add package FlaUI.Core
dotnet add package FlaUI.UIA3

• FlaUI.Core the core desktop automation library (application launching, waits, element trees)
• FlaUI.UIA3 the modern UI Automation v3 implementation (use this by default)
• FlaUI.UIA2 (optional) only needed if you’re automating older Win32/legacy applications that don’t expose UIA3 properties correctly:

dotnet add package FlaUI.UIA2

After installation, your .csproj should contain a <PackageReference> entry for each package above. Build the project once (Ctrl+Shift+B) to confirm everything restores cleanly before moving on.

4. Folder Structure

Keeping things simple and beginner-friendly, here’s the minimal Reqnroll + FlaUI project structure we’ll build:

qa-test-flaui/
|
+-- Features/
|   +-- Notepad.feature              # Gherkin scenarios
|
+-- StepDefinitions/
|   +-- NotepadSteps.cs              # Glue code between Gherkin and Page Objects
|
+-- Pages/
|   +-- NotepadWindow.cs             # Page Object Model for Notepad
|
+-- Hooks/
|   +-- Hooks.cs                     # Logging + screenshot capture
|
+-- Screenshots/                     # Auto-created at runtime for failure screenshots
|
+-- reqnroll.json                    # Reqnroll configuration (HTML report generation)
+-- qa-test-flaui.csproj

This mirrors the same separation of concerns you’d use in a Selenium framework: Features (what), StepDefinitions (glue), Pages (how), Hooks (cross-cutting concerns).

4.1 The Feature File Features/Notepad.feature

Feature files are written in Gherkin: plain English structured into Feature, Scenario, and Given/When/Then steps. Anyone on your team QA, developers, product owners can read this without knowing C#.

Feature: Notepad Text Editing
    As a user,
    I want to type text and access the File menu

Scenario: Type text into Notepad and verify it appears
    Given I launch Notepad
    When I type "Hello from Reqnroll and FlaUI!" into the editor
    Then I click Page Setup option under File menu

Right-click inside the feature file and choose Generate Step Definitions Reqnroll will scan the steps and offer to scaffold matching method signatures for you.

4.2 The Page Object Model Pages/NotepadWindow.cs

This class is the only place in the entire framework that knows how to interact with Notepad’s UI. If Notepad’s layout changes, or you swap the target app, you only edit this file step definitions stay untouched. Keeping this layer isolated is also what keeps test automation maintenance costs down as your framework grows.

using FlaUI.Core;
using FlaUI.Core.AutomationElements;
using FlaUI.Core.Definitions;
using FlaUI.Core.Tools;
using FlaUI.UIA3;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Application = FlaUI.Core.Application;

namespace Qa_Test_Flaui.Objects.Windows
{
    public class NotepadWindow : IDisposable
    {
        private readonly Application _app;
        private readonly UIA3Automation _automation;
        private readonly Window _mainWindow;

        public NotepadWindow()
        {
            Process.Start("notepad.exe");
            _automation = new UIA3Automation();
            _mainWindow = Retry.WhileNull(
                () => _automation.GetDesktop()
                    .FindFirstDescendant(cf => cf.ByName("Untitled - Notepad"))
                    ?.AsWindow(),
                TimeSpan.FromSeconds(10))
                .Result;
            Thread.Sleep(5000);
        }

        private const string FileTab = "File";
        private const string PageSetupSubTab = "Page setup";

        private AutomationElement GetEditorElement()
        {
            Console.WriteLine("---> Get Editor Main Element: " + _mainWindow.Title);
            return _mainWindow.FindFirstDescendant(cf => cf.ByName("Text editor"));
        }

        public void TypeText(string text)
        {
            var editor = GetEditorElement();
            editor.Focus();
            editor.AsTextBox().Enter(text);
        }

        public void OpenPageSetUp()
        {
            _mainWindow.FindFirstDescendant(
                 cf => cf.ByName(FileTab)).Click();
            Thread.Sleep(2000);
            _mainWindow.FindFirstDescendant(
                 cf => cf.ByName(PageSetupSubTab)).Click();
        }
    }
}

4.3 Step Definitions StepDefinitions/NotepadSteps.cs

Step definitions are the glue layer. They parse the Gherkin text, call methods on the Page Object, and make assertions.

using NUnit.Framework;
using Qa_Test_Flaui.Objects.Windows;
using Reqnroll;

namespace qa_test_flaui.StepDefinitions
{
    [Binding]
    public class NotepadSteps
    {
        private readonly ScenarioContext _scenarioContext;
        private NotepadWindow _notepad;

        public NotepadSteps(ScenarioContext scenarioContext)
        {
            _scenarioContext = scenarioContext;
        }

        [Given(@"I launch Notepad")]
        public void GivenILaunchNotepad()
        {
            _notepad = new NotepadWindow();
            // Store in ScenarioContext so Hooks can access it (e.g., to close it after the scenario)
            _scenarioContext["NotepadWindow"] = _notepad;
        }

        [When(@"I type ""(.*)"" into the editor")]
        public void WhenITypeIntoTheEditor(string text)
        {
            _notepad.TypeText(text);
        }

        [Then("I click Page Setup option under File menu")]
        public void ThenIClickPageSetupOptionUnderFileMenu()
        {
            _notepad.OpenPageSetUp();
        }
    }
}

Key things to notice for beginners:

• [Binding] tells Reqnroll “this class contains step definitions.”
• The regular expressions in [Given], [When], [Then] attributes match the Gherkin text, and (.*) captures the string in quotes as a method parameter.
• We store the NotepadWindow instance in ScenarioContext a dictionary-like object that Reqnroll shares across step definitions and hooks within the same scenario. This is how Hooks will later access it to close Notepad automatically.

4.4 Hooks Hooks/Hooks.cs

Hooks handle cross-cutting concerns that shouldn’t clutter your step definitions: logging every step, capturing screenshots on failure, and cleaning up resources.

using FlaUI.Core.Capturing;
using NUnit.Framework;
using Qa_Test_Flaui.Objects.Windows;
using Reqnroll;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Qa_Test_Flaui.Objects.Hooks
{
    [Binding]
    public class Hooks
    {
        private readonly ScenarioContext _scenarioContext;
        // ThreadLocal prevents log mixing when running tests in parallel
        private static readonly ThreadLocal<IReqnrollOutputHelper> _outputHelperContainer = new();

        public Hooks(ScenarioContext scenarioContext)
        {
            _scenarioContext = scenarioContext;
        }

        [BeforeScenario]
        public void BeforeScenario(IReqnrollOutputHelper outputHelper)
        {
            // Store the current scenario's output helper in the thread container
            _outputHelperContainer.Value = outputHelper;
        }

        [AfterScenario]
        public void AfterScenario(IReqnrollOutputHelper outputHelper)
        {
            // Clear the value after the scenario finishes to prevent memory leaks
            _outputHelperContainer.Value = null;
            String strPath = TakeScreenshot();
            outputHelper.AddAttachment(strPath);
        }

        /// <summary>
        /// Globally accessible method to write logs to the Reqnroll test output.
        /// </summary>
        public static void AttachStepLog(string message)
        {
            Console.WriteLine("---> AttachStepLog in...: ");
            if (_outputHelperContainer.Value != null)
            {
                Console.WriteLine("---> AttachStepLog IF in...: " + message);
                _outputHelperContainer.Value.WriteLine(message);
            }
        }

        public static string TakeScreenshot()
        {
           string fullPath = "";
            try
            {
                string projectRoot = AppContext.BaseDirectory.Split(
             new[] { $"{Path.DirectorySeparatorChar}bin{Path.DirectorySeparatorChar}" },
             StringSplitOptions.None)[0];
                string reportFolderLocation = Path.Combine(projectRoot, "Screenshots");
                if (!Directory.Exists(reportFolderLocation))
                    Directory.CreateDirectory(reportFolderLocation);
                string fileName = "img-" + DateTime.Now.Ticks + ".png";
                fullPath = Path.Combine(reportFolderLocation, fileName);
                var bitmap = Capture.Screen();
                bitmap.ToFile(fullPath);
            }
            catch (Exception ex)
            {
                Console.WriteLine("******* Hooks - Screenshot Exception >>>" + ex.Message);
            }
            return fullPath;
        }
    }
}

What’s happening here, step by step:

• [BeforeTestRun] runs once before any scenario we use it to ensure the Screenshots folder exists.
• [BeforeScenario] and [BeforeStep] log progress to the console (and therefore to the NUnit test output), so when you’re troubleshooting a failure you can see exactly which step the test reached.
• [AfterStep] checks _scenarioContext.TestError if a step threw an exception (an assertion failure or an exception from FlaUI), we immediately capture a full-screen screenshot using FlaUI.Core.Capturing.Capture.
• TestContext.AddTestAttachment links that screenshot file directly into the NUnit test result, so it shows up when you view results in Test Explorer or in the generated HTML report.
• [AfterScenario] disposes of the Notepad process so it doesn’t linger in the background between test runs a common source of “flaky” desktop test suites is leftover processes from previous failed runs.

5. reqnroll.json Generating HTML Test Results

Reqnroll uses a reqnroll.json file at the project root to control runtime behavior, including generating a Living Documentation-style HTML report after test execution.

Create reqnroll.json in the project root:

{
  "$schema": "https://schemas.reqnroll.net/reqnroll-config-latest.json",
  "bindingAssemblies": [
  ],
  "formatters": {
    "html": {
      "outputFilePath": "report/reqnroll_report.html"
    }
  }
}

6. Execute Your Script Using the NUnit Command

You have two common ways to run your tests: through Visual Studio’s Test Explorer (great during development) and through the NUnit Console Runner (essential for CI/CD pipelines and command-line execution).

Build the project first

This command compiles the automation framework and generates the test assembly in the build output folder.

dotnet build

Run tests with the NUnit Console Runner

After the build completes successfully, navigate to the following directory:

Goto to this folder path: ./bin/Debug/net8.0-windows/
nunit3-console.exe qa-test-flaui.dll

The NUnit Console Runner will:

• Discover all Reqnroll scenarios.
• Execute the automation test suite.
• Display the execution progress in the console.

After the test execution completes successfully, the framework automatically generates a Reqnroll HTML Report, providing a detailed overview of the execution.

Need a Production-Ready Desktop Automation Framework?

Talk to Our QA Experts

7. Analyze the Test Result

qa-test-flaui/
└── bin/Debug/net8.0-windows/report/
                └── reqnroll_report.html

Open the following file in any web browser to view the execution dashboard:

Troubleshooting checklist

These are the most common issues teams hit when running this Reqnroll and FlaUI test suite for the first time.

8. Inspecting UI Elements Using FlaUInspect

FlaUInspect is a free Windows UI Automation inspector. Use it to find the AutomationId, Name, ControlType, and ClassName of any element before writing a locator.

8.1 Launching FlaUInspect

Download the latest release from the FlaUInspect GitHub releases page and extract it (no installation required).

Run as Administrator and open FlaUInspect.exe. It opens a window with a tree view on the left and a properties panel on the right.

Step to Use Hover Mode:

• Click the Hover Mode button in the inspection tool’s toolbar to activate it.
• Move your mouse cursor over the application window you want to inspect.
• Press and hold the Ctrl key on your keyboard while keeping the mouse hovered over the specific UI element.

Note: Inspect elements like the Window Title or File Menu button as shown below.

Conclusion

This Reqnroll tutorial walked you through building a complete Windows desktop automation framework with FlaUI and NUnit from installing the Reqnroll Visual Studio extension and scaffolding the project, through building a Page Object Model, step definitions, and hooks for Notepad, to running your suite from the command line and reading the generated HTML report. With FlaUInspect in your toolkit for locating elements, you now have everything needed to extend this same pattern to a real, production desktop application.

Frequently Asked Questions

WinAppDriver for Desktop Automation Testing Guide

by Rajesh K | Mar 13, 2026 | Desktop App Automation Testing, Blog, Latest Post | 0 comments

Desktop Automation Testing continues to play a critical role in modern software quality, especially for organizations that rely heavily on Windows-based applications. While web and mobile automation dominate most conversations, desktop applications still power essential workflows across industries such as banking, healthcare, manufacturing, and enterprise operations. As a result, ensuring their reliability is not optional; it is a necessity. However, testing desktop applications manually is time-consuming, repetitive, and often prone to human error. This is exactly where WinAppDriver steps in.

WinAppDriver, also known as Windows Application Driver, is Microsoft’s automation tool designed specifically for Windows desktop applications. More importantly, it follows the WebDriver protocol, which means teams already familiar with Selenium or Appium can quickly adapt without learning an entirely new approach. In other words, WinAppDriver bridges the gap between traditional desktop testing and modern automation practices.

In this guide, you will learn how to set up WinAppDriver, create sessions, locate elements, handle popups, perform UI actions, and build real automation tests using C#. Whether you are just getting started or looking to strengthen your desktop automation strategy, this guide will walk you through everything step by step.

What Is WinAppDriver?

At its core, WinAppDriver is a UI automation service for Windows applications. It allows testers and developers to simulate real user interactions such as clicking buttons, entering text, navigating windows, and handling dialogs.

What makes it particularly useful is its ability to automate multiple types of Windows applications, including:

• Win32 applications
• WPF (Windows Presentation Foundation) applications
• UWP (Universal Windows Platform) applications

Because of this wide support, WinAppDriver fits naturally into enterprise environments where different technologies coexist.

Even better, it follows the same automation philosophy used in Selenium. So instead of reinventing the wheel, you can reuse familiar concepts like:

• Driver sessions
• Element locators
• Actions (click, type, select)
• Assertions

This familiarity significantly reduces the learning curve and speeds up adoption.

Why Use WinAppDriver for Desktop Automation Testing?

Before diving into implementation, it is important to understand why WinAppDriver is worth using.

First, it provides a standardized way to automate desktop UI interactions. Without it, teams often rely on manual testing or fragmented tools that are hard to maintain.

Second, it supports multiple programming languages such as:

• C#
• Java
• Python
• JavaScript
• Ruby

This flexibility allows teams to integrate WinAppDriver into their existing tech stack without disruption.

Additionally, WinAppDriver works well for real-world scenarios. Desktop applications often include:

• Multiple windows
• Popups and dialogs
• Keyboard-driven workflows
• System-level interactions

WinAppDriver is built to handle these complexities effectively.

Installing WinAppDriver

Getting started with WinAppDriver is straightforward. First, download the installer:

WindowsApplicationDriver.msi

Once downloaded, follow the standard installation process:

• Double-click the installer
• Follow the setup wizard
• Accept the license agreement
• Complete installation

By default, WinAppDriver is installed at:

C:\Program Files (x86)\Windows Application Driver

Before running any tests, make sure to enable Developer Mode in Windows settings. This step is essential and often overlooked.

Launching WinAppDriver

After installation, the next step is to start the WinAppDriver server.

You can launch it manually:

• Search for Windows Application Driver in the Start menu
• Right-click and select Run as Administrator

Alternatively, you can start it programmatically, which is useful for automation frameworks:

ProcessStartInfo startApp = new ProcessStartInfo();

startApp.FileName = @"C:\Program Files (x86)\Windows Application Driver\WinAppDriver.exe";

Process.Start(startApp);

Using a code-based startup ensures consistency and removes manual dependency during test execution.

Creating an Application Session

Once the server is running, you need to create a session to interact with your application.

Here’s a basic example:

AppiumOptions options = new AppiumOptions();

options.AddAdditionalCapability("app", @"C:\notepad.exe");

options.AddAdditionalCapability("deviceName", "WindowsPC");

WindowsDriver<WindowsElement> driver =
new WindowsDriver<WindowsElement>(
new Uri("http://127.0.0.1:4723"), options);

This step is critical because it establishes the connection between your test and the application. Without a valid session, no automation can take place.

Working with Windows and Application State

Desktop applications often involve multiple windows. Therefore, handling window state becomes essential.

For example, you can retrieve the current window title:

string windowTitle = driver.Title;

Console.WriteLine(windowTitle);

This simple check helps confirm that the correct window is active before performing further actions.

Handling Popup Windows

Popups are one of the most common causes of test failures in desktop automation. Therefore, handling them correctly is crucial.

Here’s a typical approach:

var popup = driver.FindElementByName("Popup Title");

popup.Click();

driver.SwitchTo().Window(driver.WindowHandles.Last());

In this flow:

• The popup is identified
• An action is performed
• The driver switches to the latest window

This ensures your test continues in the correct context.

Element Locator Strategies

Choosing the right locator strategy directly impacts test stability.

AccessibilityId (Recommended)

WindowsElement element = driver.FindElementByAccessibilityId("AutomationId");

This is the most stable and preferred option.

Name Locator

driver.FindElementByName("Open");

Useful for visible labels.

ClassName Locator

driver.FindElementByClassName("Button");

Helpful for identifying control types.

XPath Locator

driver.FindElementByXPath("//Window/Button[1]");

Flexible, but should be used cautiously as it is more fragile.

Performing UI Actions

Once elements are located, you can interact with them.

To enter text:

element.SendKeys("Sample Text");

To clear text:

element.Clear();

To click:

element.Click();

To read values:

string value = element.GetAttribute("value");

These actions form the foundation of most automation workflows.

Mouse Actions

Some interactions require more than simple clicks.

For double-click:

Actions actions = new Actions(driver);

actions.DoubleClick(element).Perform();

For right-click:

actions.ContextClick(element).Perform();

These are especially useful for context menus and file operations.

Keyboard Commands

SendKeys.SendWait("{F5}");
SendKeys.SendWait("{ENTER}");
SendKeys.SendWait("^s");
SendKeys.SendWait("{ESC}");

Using keyboard actions makes your tests more realistic and closer to actual user behavior.

Creating a Desktop Root Session

Sometimes, you need to interact with the entire desktop instead of a single app.

Here’s how you create a root session:

var options = new AppiumOptions();

options.AddAdditionalCapability("app", "Root");

options.AddAdditionalCapability("deviceName", "WindowsPC");

var session = new WindowsDriver<WindowsElement>(
new Uri("http://127.0.0.1:4723"), options);

This approach is particularly useful for:

• File dialogs
• System popups
• External windows

Required NuGet Packages

• Appium.WebDriver
• NUnit
• NUnit3TestAdapter
• Microsoft.NET.Test.Sdk

Complete NUnit Test Example

using NUnit.Framework;
using OpenQA.Selenium.Appium;
using OpenQA.Selenium.Appium.Windows;
using System;

namespace WinAppDriverDemo
{
  [TestFixture]
  public class NotepadTest
  {
      private WindowsDriver<WindowsElement> driver;

      [SetUp]
      public void Setup()
      {
          AppiumOptions options = new AppiumOptions();

          options.AddAdditionalCapability("app", @"C:\Windows\System32\notepad.exe");
          options.AddAdditionalCapability("deviceName", "WindowsPC");

          driver = new WindowsDriver<WindowsElement>(
              new Uri("http://127.0.0.1:4723"),
              options);

          driver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(5);
      }

      [Test]
      public void EnterTextInNotepad()
      {
          WindowsElement textArea = driver.FindElementByClassName("Edit");

          textArea.SendKeys("Hello WinAppDriver Automation");

          string title = driver.Title;
          Assert.IsTrue(title.Contains("Notepad"));
      }

      [TearDown]
      public void TearDown()
      {
          driver.Quit();
      }
  }
}

Best Practices for Stable Desktop Automation

• Prefer AccessibilityId over XPath
• Always wait for elements to be visible
• Handle popups using proper window switching
• Use Root sessions for system-level interactions

In practice:

• A stable locator is better than a clever locator
• A ready element is better than a rushed interaction
• A dedicated session is better than forcing one session to handle everything

These small decisions significantly reduce flaky tests and improve long-term maintainability.

Conclusion

WinAppDriver provides a powerful yet approachable way to implement Desktop Automation Testing for Windows applications. It combines the familiarity of WebDriver with the flexibility needed for real desktop environments. By following the right setup, using stable locators, handling popups correctly, and structuring tests properly, teams can build reliable automation frameworks that scale over time. Ultimately, success with WinAppDriver is not just about tools it is about building a strategy that prioritizes stability, clarity, and maintainability.

Want to build a reliable WinAppDriver framework for your team? Get expert guidance tailored to your use case.

Talk to an Automation Expert

Frequently Asked Questions

TestComplete Features Every QA Engineer Should Know

by Rajesh K | Mar 13, 2026 | Desktop App Automation Testing, Blog, Latest Post | 0 comments

Modern software teams are expected to deliver high-quality applications faster than ever. However, as desktop applications become more complex, relying only on manual testing can slow down release cycles and increase the risk of defects. This is where understanding the TestComplete features becomes valuable for QA teams looking to automate their testing processes efficiently. TestComplete, developed by SmartBear, is a powerful automation tool designed to test desktop, web, and mobile applications. It is especially known for its strong desktop testing capabilities, supporting technologies like .NET, WPF, Java, and Delphi. With features such as keyword-driven testing, intelligent object recognition, and multi-language scripting, TestComplete helps teams automate repetitive tests, improve test coverage, and deliver more reliable software releases.

In this guide, we’ll walk through the key TestComplete features, explain how they work, and compare them with other automation tools. By the end, you’ll have a clear understanding of how TestComplete helps QA teams automate desktop applications faster and more reliably.

What is TestComplete?

TestComplete is a functional UI test automation tool created by SmartBear. It allows teams to automate end-to-end tests for:

• Desktop applications
• Web applications
• Mobile applications

QA teams typically use TestComplete for tasks like:

• Regression testing
• UI validation
• Functional testing
• End-to-end workflow testing

One of the most attractive aspects of TestComplete is its flexibility in scripting languages. Teams can write automation scripts using:

• Python
• JavaScript
• VBScript
• JScript
• DelphiScript
• C++Script
• C# Script

This flexibility makes it easier for teams to integrate TestComplete into existing testing frameworks and workflows.

Key TestComplete Features for Desktop Test Automation

Intelligent Object Recognition

One of the most impressive TestComplete features is its object recognition capability.

Instead of interacting with UI elements based on fragile screen coordinates, TestComplete identifies application components based on their properties and hierarchy.

In simpler terms, the tool understands the structure of the application UI. So even if the layout changes slightly, the automation script can still locate the correct elements.

Why this matters

Without strong object recognition, automation scripts often break when developers update the interface. TestComplete reduces this problem significantly.

Example

Imagine testing a desktop login form.

A coordinate-based test might click on a button like this:

Click (X:220, Y:400)

But if the interface changes, the script fails.

With TestComplete, the script targets the object itself:

Aliases.MyApp.LoginButton.Click()

This approach makes automation far more reliable and easier to maintain.

Keyword-Driven Testing (Scriptless Automation)

Not every tester is comfortable writing code. TestComplete solves this by offering keyword-driven testing.

Instead of writing scripts, testers can create automated tests using visual steps such as:

• Click Button
• Enter Text
• Verify Property
• Open Application

These steps are arranged in a structured workflow that defines the automation process.

Why QA teams like this feature

Keyword testing allows manual testers to participate in automation, which helps teams scale their automation efforts faster.

Benefits include:

• Faster test creation
• Lower learning curve
• Better collaboration between testers and developers

Multiple Scripting Language Support

Another major advantage of TestComplete is that it supports multiple scripting languages.

Different teams prefer different languages depending on their technology stack.

This flexibility allows organizations to choose the language that best fits their workflow.

Record and Playback Testing

For teams just starting with automation, TestComplete’s record-and-playback feature is extremely helpful.

Here’s how it works:

• Start recording a test session
• Perform actions in the application
• Save the recording
• Replay the test whenever needed

The tool automatically converts recorded actions into automation steps.

When is this useful?

Record-and-playback works well for:

• Simple regression tests
• UI workflows
• Quick automation prototypes

However, most mature QA teams combine recorded tests with custom scripts to make them more stable.

Cross-Platform Testing Support

Although TestComplete is widely known for desktop automation, it also supports testing across multiple platforms.

Teams can automate tests for:

• Desktop applications
• Web applications
• Mobile apps

This allows organizations to maintain one centralized automation platform instead of managing multiple tools.

Supported desktop technologies

• Windows Forms
• WPF
• .NET
• Java
• Delphi
• C++

This makes it especially useful for enterprise desktop applications that have been around for years.

Data-Driven Testing

Another powerful feature is data-driven testing, which allows the same test to run with multiple data inputs.

Instead of creating separate tests for each scenario, testers can connect their automation scripts to external data sources.

Common data sources include:

• Excel spreadsheets
• CSV files
• Databases
• Built-in data tables

With data-driven testing, one script can validate all these scenarios automatically.

This approach significantly reduces duplicate tests and improves coverage.

Detailed Test Reports and Logs

Understanding why a test failed is just as important as running the test itself.

TestComplete generates detailed execution reports that include:

• Test steps performed
• Screenshots of failures
• Execution time
• Error messages
• Debug logs

These reports make it easier for QA teams and developers to identify and fix issues quickly.

CI/CD Integration

Modern software teams rely heavily on continuous integration and continuous delivery pipelines.

TestComplete integrates with popular CI/CD tools such as:

• Jenkins
• Azure DevOps
• Git
• Bitbucket
• TeamCity

This allows automation tests to run automatically during:

• Code commits
• Build pipelines
• Release validation

The result is faster feedback and improved release confidence.

TestComplete vs Other Automation Tools

Key takeaway

TestComplete is often the preferred choice for teams that need reliable desktop automation and enterprise-level capabilities.

Example: Automating a Desktop Banking System

Consider a QA team working on a desktop banking application.

Before automation, the team manually tested features like:

• User login
• Transaction processing
• Account updates
• Report generation

Regression testing took two to three days every release cycle.

After implementing TestComplete:

• Login tests were automated using keyword testing.
• Transaction workflows were scripted using Python.
• Multiple users were tested through data-driven testing.
• Tests were integrated with Jenkins pipelines.

Regression testing time dropped from three days to just a few hours.

This allowed the team to release updates faster without sacrificing quality.

Benefits of Using TestComplete

Best Practices for Using TestComplete

• Use object mapping – Organize UI elements in a repository for better test stability.
• Combine keyword and scripted tests – Use keyword tests for simple workflows and scripts for complex scenarios.
• Implement data-driven testing – Improve test coverage without duplicating scripts.
• Integrate with CI/CD – Run automation tests during build pipelines.
• Maintain clear reporting – Use logs and screenshots to quickly identify failures.

Conclusion

TestComplete offers a powerful set of features that make desktop test automation faster, more reliable, and easier to scale. With capabilities like intelligent object recognition, keyword-driven testing, multi-language scripting, and CI/CD integration, it helps QA teams automate complex workflows while reducing manual effort. For organizations that rely heavily on Windows desktop applications, TestComplete provides the flexibility and stability needed to build efficient automation frameworks. When implemented with the right testing strategy, it can significantly improve test coverage, speed up regression cycles, and support faster, high-quality software releases.

Looking to improve your desktop test automation with TestComplete? Our QA experts can help you build scalable automation solutions and enhance testing efficiency.

Contact Our QA Experts

Frequently Asked Questions

TestComplete Remote Desktop: Fix RDP Minimized Test Failures

by Rajesh K | Mar 9, 2026 | Desktop App Automation Testing, Blog, Latest Post | 0 comments

Automation testing helps software teams deliver reliable applications faster. By automating repetitive validation tasks, QA engineers can ensure that applications behave consistently across releases while reducing manual testing effort. However, teams performing TestComplete Remote Desktop testing on remote machines using Remote Desktop Protocol (RDP) often encounter an unexpected problem: automated GUI tests fail when the Remote Desktop session is minimized. This issue frequently affects testers using TestComplete, a powerful automation tool designed for desktop, web, and mobile testing. When running TestComplete automation remotely, engineers may assume that minimizing the Remote Desktop window should not affect the automation process. Unfortunately, Windows behaves differently.

When an RDP session is minimized, Windows automatically stops rendering the graphical interface of the remote machine. This optimization helps reduce resource usage, but it also causes problems for GUI-based automation tools. Since automation frameworks like TestComplete rely on visible UI elements such as buttons, text boxes, menus, and dialog windows, the automation engine can no longer interact with the application interface.

As a result, testers experience issues such as:

• UI elements not being detected
• Automated clicks failing
• Object recognition errors
• Tests stopping unexpectedly

For QA teams running automation in remote testing environments, CI/CD pipelines, or centralized test labs, this behavior can lead to unreliable test execution and wasted debugging time.

The good news is that this issue has a simple and reliable solution. By applying a small Windows registry tweak on the machine that initiates the Remote Desktop connection, testers can keep the remote GUI active even when the RDP window is minimized.

In this guide, we’ll explain:

• Why TestComplete Remote Desktop Testing fails when RDP is minimized
• How Windows handles remote GUI rendering
• The registry fix that prevents automation failures
• Best practices for running TestComplete tests on remote machines
• How to build a stable remote automation environment

By the end of this article, you’ll have a clear understanding of how to run reliable TestComplete automation in Remote Desktop environments without interruptions.

Why TestComplete Remote Desktop Testing Fails When RDP Is Minimized

When automation tests run on a remote machine through Remote Desktop, the graphical interface of the system is transmitted to the client computer.

However, Windows introduces a performance optimization.

When the Remote Desktop window is minimized:

• Windows assumes the user is not viewing the remote screen
• The operating system stops rendering the graphical interface
• The session switches into a GUI-less mode

The application continues running, but the visual interface disappears.

According to the uploaded guide, this behavior occurs because Windows disables the graphical rendering of the remote desktop when the RDP window is minimized.

For everyday users, this optimization is harmless.

But for GUI automation tools like TestComplete, it creates serious problems.

Automation tools rely on visible UI components to:

• Locate elements
• Simulate user interactions
• Validate interface behavior

Without the rendered interface, TestComplete cannot detect UI objects, causing automation failures.

Common Symptoms of the TestComplete RDP Minimized Issue

QA engineers typically encounter the following problems:

• Tests fail only when Remote Desktop is minimized
• UI objects cannot be identified
• Automated clicks do not work
• Scripts that worked earlier suddenly fail

Here’s a simple breakdown.

The Registry Fix for Reliable TestComplete Remote Desktop Testing

Fortunately, there is a reliable workaround.

By modifying a registry setting on the local machine used to connect via Remote Desktop, you can force Windows to keep the remote GUI active even when the RDP window is minimized.

The solution involves adding a DWORD value called RemoteDesktop_SuppressWhenMinimized.

Setting this value to 2 prevents Windows from suppressing the GUI rendering.

This ensures that automation tools like TestComplete continue interacting with UI elements even when the RDP session is minimized.

Step-by-Step Guide to Fix the TestComplete RDP Minimized Issue

Step 1: Open the Windows Registry Editor

Press Windows + R, then type:

regedit

Press Enter to open the Registry Editor.

Step 2: Navigate to the Terminal Server Client Key

Choose one of the following registry paths.

For Current User

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client

For All Users

HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client

Step 3: Create the Required DWORD Value

Create a new DWORD entry with the following configuration.

• Name: RemoteDesktop_SuppressWhenMinimized
• Value: 2

This tells Windows to keep the remote GUI active even when the RDP session is minimized.

Step 4: Apply the Fix for 64-bit Windows

If your machine uses 64-bit Windows, repeat the same step in:

HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Terminal Server Client

or

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal Server Client

Add the same DWORD value.

RemoteDesktop_SuppressWhenMinimized = 2

Step 5: Restart the Remote Desktop Session

After updating the registry:

• Close Registry Editor
• Disconnect the Remote Desktop session
• Reconnect to the remote machine

Your TestComplete Remote Desktop Testing environment should now run automation reliably.

Running TestComplete Tests on a Remote Machine

Imagine a QA team running nightly regression tests using TestComplete.

Their environment includes:

• Dedicated test machine
• Remote Desktop access
• Scheduled automation runs

During test execution, an engineer minimizes the Remote Desktop window.

Suddenly:

• Automation fails
• TestComplete cannot find UI elements
• Regression tests stop halfway

After applying the registry fix described earlier, the team can minimize the RDP session without breaking the automation.

Now their automation environment:

• Runs tests reliably overnight
• Supports remote monitoring
• Prevents random automation failures

Benefits of This TestComplete Remote Desktop Testing Fix

Best Practices for Running TestComplete Tests on Remote Machines

Use Dedicated Automation Machines

Automation environments should run on machines that are not used for daily development tasks.

This avoids interruptions like:

• Session logouts
• Screen locks
• Unexpected reboots

Avoid Locking the Remote Machine

Locking the screen can also affect GUI rendering.

Ensure the session remains active during automation runs.

Integrate Automation with CI/CD Pipelines

Many QA teams run automation through CI/CD systems such as:

• Jenkins
• GitHub Actions
• Azure DevOps

These systems help automate test execution and reporting.

TestComplete Remote Desktop Testing vs Local Automation

Final Thoughts

Running GUI automation in Remote Desktop environments can introduce unexpected issues if the system configuration is not optimized for automation tools. One of the most common problems QA teams encounter is the TestComplete RDP minimized issue, where tests fail because the remote graphical interface stops rendering. Fortunately, a simple registry tweak can prevent this behavior and ensure your automation environment remains stable. By keeping the remote GUI active, testers can run automation scripts reliably even when the Remote Desktop session is minimized.

Frequently Asked Questions