Stepping into desktop automation: The map before the road

TL;DR:

I’m starting a new journey: building desktop automation from scratch.
Currently evaluating the app, existing tools, and architecture options.
Not rushing into coding. First shaping a scalable, maintainable TAA.
Learning desktop tooling while keeping the big picture clear.
Sharing this process so others on the same path know they’re not alone.

Introduction

Every new automation project begins the same way: with a quiet moment of looking at the product, the process, the people… and trying to understand what lives underneath the surface.

For years, my world was the browser. HTML, DOM, APIs, selectors, networks, pipelines—I knew their rhythm. Desktop automation, on the other hand, is a different landscape: older roots, richer UI trees, and sometimes mysterious shadows where element inspectors don’t want to cooperate.

And this is exactly where my new journey begins.

The first step: Before building, I listen

Right now, I’m in the initial evaluation phase, my favorite part of any automation story because this is where you get to meet the product without rushing to “fix” anything.

I’m doing three things:

1. Understanding the SUT (System Under Test)

Not just what the app does, but how it behaves, where it hides complexity, and what patterns it follows.

Does it expose stable automation properties?
Do inspectors see the UI consistently?
Where does the app “breathe” and where does it resist?

This is the phase where the application starts telling its story.

2. Investigating What Already Exists

Before touching the framework or writing a single test, I want to honor what came before.

What tools were used?
What attempts were made?
What succeeded, what struggled, and what was abandoned?

There is always some hidden knowledge left in old attempts, breadcrumbs of lessons that make the future solution stronger. Instead of rushing into rebuilding, I’m assessing whether the existing solution can continue supporting the team as we gradually transition into a more robust architecture.

3. Sketching the future architecture (TAA)

Even while I’m still learning the specifics of desktop toolchains, the bigger picture is already forming:

A test architecture that scales, not suffocates
A structure that avoids brittle scripts and encourages maintainability
A solution the team can trust, not fear
And a framework that integrates naturally into the delivery flow instead of slowing it down

In short: confidence first, complexity second.

I may still be learning the deeper C# ecosystem, but the architectural thinking is already there: what layers I need, how to separate concerns, how to make the framework readable, extendable, future-proof. The commands will come, the strategy isn’t fully defined yet, but its shape is becoming clearer each day.

What this series will be about

This article is Episode 1 of a longer professional journal: my journey in building a desktop automation solution from the ground up in 2025 (2026 already).

I’ll be sharing:

How I explore a legacy-rich desktop application
What tools work (and which surprisingly don’t)
How I design the test architecture step by step
My decision-making process and trade-offs
Failures, “Aha!” moments, and the exact reasoning behind choices
How we gradually bring automation into the delivery workflow
How the framework evolves from nothing to something the team relies on

I want this series to be useful not only for QA engineers stepping into desktop testing, but also PMs, POs, and team leads who want to understand how automation grows, how decisions are made, and what a healthy automation journey looks like from the inside.

Somewhere out there, someone else is facing the same questions: searching the internet for desktop automation boilerplates, looking for projects to inspire from, and trying to understand how others approached the architecture before starting their own journey. You’re not alone.

And maybe this journal helps.

Conclusion

The journey starts before the code.

People often think automation begins with writing tests. It doesn’t. It begins here, evaluating, listening, mapping, imagining the architecture before the first line of code exists.

In this phase, you’re not just testing an app. You’re learning its language. And this is where my journey starts.

Stay tuned for the next episode!