Feasibilty Report for Choosing The right Desktop Automation Tool

Hi All,

I am a software engineer in Test in a Company which has been using Sikuli for past 20 years. I have managed to get rid of it but we need a new automation tool for it .We have moved all our sikuli tests to manual tests which is costing us alot of manual resources leaving us no time for exploratory or self learning processes.
I got help from various sessions in MOT and I decided to go ahead with the Ranorex for the trial period.
But there is something new out there known as RPA , Robotic Process Automation.
I have been looking into RPA aswell using the UI Path.
RPA focuses on automating the Business processes using modern AI .

I have created a basic case study listing its both Pros.
In our current QA team we have 4 Testers who are interested in progressing towards automation but remaining 3 testers are bit how I can say is not comfortable with the term automation since it includes coding.
We have really good Unit tests in our product but when it comes to E2E tests or business processes automation or testing that we donot have automated.
How can I create an effective case for my decision for either of the tools ? What criterias can make the most impact when making the decision?
I have created an SOS within my company for the automation of the boring,monotous tests that we have to do twice in a week in the form of smoke testing.


RPA tools, firstly are not testing tools, they are “process tools”. When I used Ranorex, I found it was a lot of work to maintain, mainly the people budget for automation is high, it’s often higher than you think, and often it can be very high if you write your own framework. We don’t need new frameworks, we just need ones that grow while we grow.

With that shotgun unloaded, and the echo dying away, I have one big question @mariaharis , why did you ditch your automation and go back to manual testing and think it would be survivable? (This is coming from someone who did do this myself recently.)

1 Like

@conrad.braam Well to begin with yes you are correct here. I was curious to know about how QA can be made better with RPA .And if it has a chance of making our lives easier and more productive? I couldnt find any information about it on the MOT resource.

I ditched the most bizare old tool which was apparently just a liabilty not adding any more value to the current processes. 1 or 2 resources were just painstakingly were trying to trouble shoot the failing tests.The desktop module that does need to be automated we shall keep on supporting for next 3 years but it is a very complex tool which needs regresssion and thorough testing while we are releasing twice a week. I wanted to save us the time in rather mantaining the tests why not look for the new tool.


Maintaining a dead system is draining mentally and a waste of everybodys time, I fully agree. My experience of abandoning automation was a calculated risk. It was around a huge chunk of functionality on a “new-ish” platform, and was not going to release for a long time. So I had plenty of time to build some automation for it. I think the gotcha in all automation that you build yourself, is that it costs more, but becomes easier to shift to new platforms that your existing tool does not work on.

My background is programming, so I have a pretty good idea of which bits of framework I can write and which bits are not worth writing yourself. This makes it harder to drop or abandon the framework longer term, but in this case the plan was to extend the test framework. But I had to buy time to experiment with the best way to do the extending. We did this by halting all testing for a while, since it was not in production anyway. Implementation deadlines are a way of guaranteeing a rushed setup. I’ve always worked at places where we built in-house more than half of the test tools, mainly because lots of off-the-shelf tools are pretty poor at multi-process and network distributed product testing.

Desktop apps that were not written with testability in mind are terribly hard to automate. It’s a judgement call whether you either improve the app testability (lots of ways of doing this exist) or use Ranorex or similar and just deal with the pain. Although web apps are messy, the UI automation pain is slightly less in the longer term for some reason. Good luck with choosing tools, do search around and comment on any tools related threads you find give you any clues.

Since the below article from 2018 many RPA & low-code tools have emerged: ProvarTesting, Mabl, Testim. Even Microsoft Power Platform enables you to do codeless/no-code test automation these days. Give them a trial run and see how they fit your ecosystem: system landscape, business roadmaps, and staffing skills. Be sure to pick one that does desktop applications too :wink:

1 Like

btw, @mariaharis here are some similar threads on the topic: